Xen devel - Sep 2006 - [patch] barrier support for blk{front,back}

Hi,

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

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@suse.de>


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

> 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@suse.de>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Ian Pratt wrote:
>> 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?
Trying to fix some problems of loop-file backed virtual block devices.
For SLES10 we have a patch which adds a syncronous mode to the loop
driver (by opening the file with O_SYNC).  It solves the problem of loop
doing too much buffering and screw up journaling filesystems, but is
dead slow.  When using barriers instead the performance should become
better without the risc to kill the filesystem by ignoring write
ordering.  There is also a patch in the queue (for mainline) which adds
barrier support to loop devices, attached below for reference.
> Which file systems use it, and do you see a worthwhile performance
> gain from the extra disk scheduling flexibility?
All journaling filesystems should be able to use them.  ext3 and
reiserfs do for sure, although they are not enabled by default, you need
the barrier=1 (ext3) and barrier=flush (reiser) mount options.  Don''t
know what xfs and jfs are doing by default.

No benchmarks yet, sorry.  I finished the patch just the day before the
summit on my notebook, which is way to slow for serious performance
tests.  Beside that I simply had no time yet.  I can run some next week.
> 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.
Hmm, yes, the frontend driver better should take care that there isn''t
an barrier request in flight.  Doing that should also reduce the risc to
corrupt the filesystem in the (already unlikely) case that the writes on
the host the machine is migrated from are ending up on disk after the
ones resubmitted from the host the machine is migrated to.

jetlagged greetings from europe,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>


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