This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Gerd Hoffmann" <kraxel@xxxxxxx>, "xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [patch] barrier support for blk{front,back}
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Sat, 9 Sep 2006 20:59:48 +0100
Delivery-date: Sat, 09 Sep 2006 13:00:14 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4501A9A6.2050802@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcbTa959iDx8NDLzS66oiOUvJEo9QAAmzR+A
Thread-topic: [Xen-devel] [patch] barrier support for blk{front,back}
> 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.


> 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

<Prev in Thread] Current Thread [Next in Thread>