RE: [Xen-devel] [patch] Add support for barriers to blk{back, front} drivers.

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

> > Out of interest, have you any benchmarks showing the benefits of 
> > barrier support? I'd be very interested to see them.
> 
> It's about correctness, not about performance.  I've talked 
> with Jens Axboe about it a while ago.  Barriers are 
> *required* for journaling filesystems to work reliable.  

I just don't believe that. If the underlying device doesn't support
barriers Linux should just stop issuing requests until it has the
completion notifcation back for *all* the outstanding IOs to the device,
and then start issuing the new batch of IOs.  
I'd be incredibly surprised if this is not what Linux does today for
devices that don't support barriers. [NB: you still have the issue of
disks that support write caching and lie and send the completion before
data has hit the disk, but there's nothing you can do about that from
the OS]

Barriers should just be an optimization that gives greater scheduling
flexibility. 

I'd certainly be interested to see some benchmarks with and without the
barrier support in blkfront/back.

> > Also, have you thought how this would work with blktap?  
> Does the AIO 
> > interface allow ordering constraints to be communicated to 
> the kernel?
> 
> Have a look at Documentation/block/barrier.txt for some 
> background information.
> 
> It shouldn't be a big problem to implement barriers with 
> blktap too.  I think it can't be simply passed down to the 
> block layer (like blkback does).  But it can be implement 
> with aio_fsync().  If a barrier request comes in: sync, 
> submit the write request, sync again, then go ahead with the 
> next request.  

Linux's notion of a barrier is pretty odd in that it does appear to
require the second fsync, at least according to barrier.txt. That's more
restrictive than the notion of barrier I've seen in other OSes.

> Some extra care might be needed for the disk 
> format metadata (cow images come to mind ...).

There's already care taken to ensure that metadata updates happen with
the correct ordering with respect to data writes. Adding barriers at the
data level should be totally orthogonal. 

Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel