Re: [RFC] relaxed barrier semantics

[Tejun Heo <teheo@suse.de>]

On 07/28/2010 10:08 AM, Tejun Heo wrote:
> Having writeback cache or not doesn't make any difference
> w.r.t. request ordering requirements.  If filesystems don't need the
> heavy handed ordering provided by barrier, it should just use flush
> instead of barrier.  If filesystem needs the barrier ordering, whether
> the device in question is battery backed and costs more than a house
> doesn't make any difference.

BTW, if filesystems already have code to order the requests they're
issuing, it would be *great* to phase out barrier and replace it with
simple in-stream, non-ordering flush request.  There have been several
different suggestions about how to improve barrier and most revolved
around how to transfer more information from filesystem to block layer
so that block layer can use more relaxed orderign, but the more I
think about it, it becomes clear that it doesn't belong to block layer
at all.

The only benefit of doing it in the block layer, and probably the
reason why it was done this way at all, is making use of advanced
ordering features of some devices - ordered tag and linked commands.
The latter is deprecated and the former is fundamentally broken in
error handling anyway.  Furthermore, although they do relax ordering
requirements from the device queue side, the level of flexibility is
significantly lower compared to what filesystems can do themselves.

So, yeah, let's phase it out if it isn't too difficult.

Thanks.

-- 
tejun