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

[ ... ]

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.

quoted

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.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com
--
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