WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [patch] Add support for barriers to blk{back,front} driv

To: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [patch] Add support for barriers to blk{back,front} drivers.
From: Gerd Hoffmann <kraxel@xxxxxxx>
Date: Mon, 30 Oct 2006 09:21:23 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 30 Oct 2006 00:21:50 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <8A87A9A84C201449A0C56B728ACF491E92FC@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <8A87A9A84C201449A0C56B728ACF491E92FC@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.7 (X11/20060911)
Ian Pratt wrote:
> What's the current logic for determining whether the backend advertises
> barrier support, and whether the frontend chooses to use it?

Backend:  "feature-barrier" node in xenstore.  It means the backend
understands the new BLKIF_OP_WRITE_BARRIER operation.  The node can be
either 1 or 0, depending on whenever the underlying block device
actually supports barriers or not.  Initially it is '1' unconditionally,
the only way to figure whenever the underlying block device supports
barriers is to actually submit one and see if it works.  If a barrier
write fails with -EOPNOTSUPP the backend changes the node to '0'.

The error is also propagated to the frontend so it knows barriers don't
work (and can in turn propagate that up to the filesystem driver), the
new BLKIF_RSP_EOPNOTSUPP error code is needed for that.

Frontend:  It simply submits barrier writes ;)  The backend takes care
that the new error code is used for barrier writes only (it should never
ever happen for normal writes anyway), so old frontends which don't know
about barriers (and thus never submit barrier write requests) should
never ever see the new error code.

> I guess the backend could always advertise it providing it did the
> appropriate queue drain whenever it encoutered one if the underlying
> block device didn't support barriers.

The filesystems do some best-effort handling when barrier are not
available anyway (which works ok for the non-write caching case).  IMO
the best way to handle non-working barriers is to simply let the
filesystems know, which is exactly what the patch implements:  It passes
through the capabilities of the underlying block device to the domU
instead of trying to fake something which isn't there.

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@xxxxxxx>
http://www.suse.de/~kraxel/julika-dora.jpeg

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