On Fri, 5 Dec 2008, Andi Kleen wrote:
> > And if barriers fail at random points, the user can't turn on disk cache
> > anyway (he would get data corruption if barrier write failed and hardware
> I think we already established earlier in the thread that there is no disk
So, the facts are:
* barrier support in md-raid1 deviates from the specification at
Documentation/block/barrier.txt. The specification says that requests
submitted after the barrier request hit the media after the barrier
request hits the media. The reality is that the barrier request can be
randomly aborted and the requests submitted after it hit the media before
the barrier request.
* the filesystems developed hacks to work around this issue, the hacks
involve not submitting more requests after the barrier request,
synchronously waiting for the barrier request and eventually retrying it.
These hacks suppress any performance advantage barriers could bring.
* you submit a patch that makes barriers even more often deviate from the
specification and you argue that the patch is correct because filesystems
handle this deviation.
This is runaway logic that will eventually turn Linux into unmaintainable
mess. What do you think we'll be doing when we'll be implementing barriers
into other dm targets? Do you really think it'll be fun to write code to
double-submit all metadata writes just because you and some person at
md-raid1 provided an unreliable interface?
I am again repeating: either make barriers consistent with the
specification, or remove them at all.