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] Re: [PATCH] xen block backend driver.

To: Daniel Stodden <daniel.stodden@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] xen block backend driver.
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Fri, 22 Apr 2011 05:09:04 -0400
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, "jaxboe@xxxxxxxxxxxx" <jaxboe@xxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, "konrad@xxxxxxxxxx" <konrad@xxxxxxxxxx>
Delivery-date: Fri, 22 Apr 2011 02:10:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1303413277.9571.133.camel@xxxxxxxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1303333543-5915-1-git-send-email-konrad.wilk@xxxxxxxxxx> <1303333543-5915-2-git-send-email-konrad.wilk@xxxxxxxxxx> <20110421034016.GB11501@xxxxxxxxxxxxx> <1303412592.9571.126.camel@xxxxxxxxxxxxxxxxxxxxxxx> <20110421190606.GA10793@xxxxxxxxxxxxx> <1303413277.9571.133.camel@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Apr 21, 2011 at 12:14:37PM -0700, Daniel Stodden wrote:
> > There is a huge userbase of guests out there that does rely on it.
> 
> Which ones? Old blkfront would have make a difference back then when
> barriers used to be an option, but it never actually declared it, right?

Pre-Linux 2.6.37 guests using reiserfs actually relied on the queue
flushing.  This includes a lot of SLES installation which are still
in common use.  There's only two options to make sure they work:

 (1) keep the original barrier semantics and flush the queue
 (2) do not advertize "barrier" support at all, and make sure to submit
   every I/O we get with the FUA bit.

In practice (2) is going to be faster for most real-life workloads.  So
maybe you should just drop the old "barrier" support and just send
requests with the FUA bit set for now, until you have proper flush
and fua support in the protocol.

> Weeeeeelll, I certainly hope it can deal with backends which never got
> to see those headers. :o)

They probably try to handle it, no idea how correct the handling is
in the end.


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