RE: [Xen-devel] [patch] barrier support for blk{front,back}

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

> This patch adds support for barriers to blk{back,front} drivers.

It's good to see barrier supported added. 

Out of interest, what was your motivation for adding it?  Which file
systems use it, and do you see a worthwhile performance gain from the
extra disk scheduling flexibility?

We are going to have to think through what the impact of this would be
in the live relocation block safety optimizations Andy Warfield
described at the summit. The simple thing is just to revert to stalling
until the backend gives the all clear if there's a barrier in the queue.

Thanks,
Ian

 
> protocol changes:
>  * There is a new operation (BLKIF_OP_WRITE_BARRIER)
>    to pass on barrier requests.
>  * There is a new state (BLKIF_RSP_EOPNOTSUPP) to indicate
>    unsupported operations (barrier writes may fail depending
>    on the underlying block device).
>  * A new xenstore node named "feature-barrier" indicates the
>    backend is able to handle barrier writes.  The value can
>    be 1 (all is fine) or 0 (underlying block device doesn't
>    support barriers).
> 
> blkback changes:  Add "feature-barrier" node to indicate barrier
> support, pass incoming barrier requests to the block layer using
> submit_bio(WRITE_BARRIER, bio).  Some error handling fixes to
> properly pass through barrier write failures, so the frontend
> can turn off barriers then.
> 
> blkfront changes:  Check if the backend sets "feature-barrier", if
> present switch to QUEUE_ORDERED_DRAIN mode.  Send off barrier
> requests to the backend using the new BLKIF_OP_WRITE_BARRIER
> operation.  Also some error handling for the EOPNOTSUPP case.
> 
> cheers,
> 
>   Gerd
> 
> --
> Gerd Hoffmann <kraxel@xxxxxxx>

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