Am Montag 15 Dezember 2008 schrieb Dave Chinner:

On Sun, Dec 14, 2008 at 10:02:05PM +0000, Peter Grandi wrote:

quoted

[ ... ]

quoted

But - as far as I understood - the filesystem doesn't have to
wait for barriers to complete, but could continue issuing IO
requests happily. A barrier only means, any request prior to
that have to land before and any after it after it.

It doesn't mean that the barrier has to land immediately and
the filesystem has to wait for this. At least that always was
the whole point of barriers for me. If thats not the case I
misunderstood the purpose of barriers to the maximum extent
possible.

Unfortunately that seems the case.

The purpose of barriers is to guarantee that relevant data is
known to be on persistent storage (kind of hardware 'fsync').

In effect write barrier means "tell me when relevant data is on
persistent storage", or less precisely "flush/sync writes now
and tell me when it is done". Properties as to ordering are just
a side effect.

No, that is incorrect.

Barriers provide strong ordering semantics.  I/Os issued before the
barrier must be completed before the barrier I/O, and I/Os issued
after the barrier write must not be started before the barrier write
completes. The elevators are not allowed to re-оrder I/Os around
barriers.

This is all documented in Documentation/block/barrier.txt. Please
read it because most of what you are saying appears to be based on
incorrect assumptions about what barriers do.

Hmmm, so I am not completely off track it seems ;-).

What I still do not understand then is: How can write barriers + write 
cache be slower than no write barriers + no cache? I still would expect 
write barriers + write cache be in between no barriers + write cache and 
no barriers + no cache performance wise. And would see anything else as a 
regression basically.

This doesn't go into my brain yet and I thought I understood 
Documentation/block/barrier.txt well enough before writing my article.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html