Device loses barrier support (was: Fixed patch for simple barriers.)

[Mikulas Patocka]

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
> corruption

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.

Mikulas