Re: XFS and write barriers.

[Neil Brown <neilb@suse.de>]

On Sunday March 25, dgc@sgi.com wrote:
> On Fri, Mar 23, 2007 at 09:50:55AM +0000, Christoph Hellwig wrote:
> > 
> > So yes, we could probably get rid of the check now, although I'd
> > prefer the block layer exporting an API to the filesystem to tell
> > it whether there is any point in trying to use barriers.
> 
> Ditto.

What would be the point of that interface?

If it only says "It might be worth testing", then you still have to
test.  And if you have to test, where is the value in asking in
advance.
The is no important difference between "the device said 'don't bother
trying'" and "We tried and the device said 'no'".

> > 
> > So you're retrying the whole I/O, this is probably better than trying
> > to handle this at the bio level.  I still don't quite like doing another
> > I/O from the I/O completion handler.
> 
> You're not the only one, Christoph. This may be better than trying
> to handle it at lower layers, and far better than having to handle
> it at every point in the higher layers where we may issue barrier
> I/Os. 

But I think that has to be where it is handled.
What other filesystems do is something like:

   if (barriers_supported) {
       submit barrier request;
       wait for completion
       if (fail with -EOPNOTSUPP)
             barriers_supported = 0;
   }
   if (!barriers_supported) {
        wait for other requests to complete;
        submit non-barrier request;
        wait for completion
   }
   handle_error

Obviously if you are going to issue barrier writes from multiple
places you would put this in a function...
I'm not sure that other filesystems call blkdev_issue_flush.... As you
said elsewhere, not a very effectively communicated interface.


> 
> But I *seriously dislike* having to reissue async I/Os in this
> manner and then having to rely on a higher layer's I/o completion
> handler to detect the fact that the I/O was retried to change the
> way the filesystem issues I/Os in the future. It's a really crappy
> way of communicating between layers....

md/dm do add extra complexity to the blockdev interface that I don't
think were fully considered when the interface wa designed.

We would really like a client to say "I'm starting to build a bio"
so that the device can either block that until a reconfiguration
completes, or can block any reconfiguration until the bio is fully
built and submitted (or aborted).
Once you have that bio-being-built handle, it would probably make
sense to test 'are barriers supported' for that bio without having to
submit an IO..

NeilBrown