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] blkfront problem in pvops kernel when barriers enabled

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] blkfront problem in pvops kernel when barriers enabled
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Wed, 07 Sep 2011 11:58:38 -0700
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Marek Marczykowski <marmarek@xxxxxxxxxxxx>
Delivery-date: Wed, 07 Sep 2011 12:03:02 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110907174314.GM32190@xxxxxxxxxxxx>
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: <4E6357C6.6050101@xxxxxxxxxxxx> <20110906163213.GC5264@xxxxxxxxxxxx> <4E665572.7080009@xxxxxxxxxxxx> <20110907014741.GD30639@xxxxxxxxxxxx> <4E67AB39.70801@xxxxxxxx> <20110907174314.GM32190@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0
On 09/07/2011 10:43 AM, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 07, 2011 at 10:34:49AM -0700, Jeremy Fitzhardinge wrote:
>> On 09/06/2011 06:47 PM, Konrad Rzeszutek Wilk wrote:
>>> (on 3.1rc2) Looking to xenstore now there is 'feature-flush-cache=1' and
>>> no 'feature-barrier'. So it is ok.
>>> <scratches head>
>>>
>>> I can only think of 2.6.38-3 XenOLinux doing it - and it is a bug
>>> to do it. It really ought to _not_ advertise 'feature-barrier' and
>>> instead advertise 'feature-flush-cache'.
>> Does that mean that older guests which don't understand flush-cache will
>> be left with no way to force writes to stable storage?  Seems to me that
> Correct.
>> even if the backend would prefer flush-cache, it should also advertise
>> barriers.
> But doing it incorrectly is bad - really bad.

Well, there's "bad performance" and "bad oops we lost data".  If the
backend emulates a barrier by doing a drain, flush, write, drain, flush
then I think that should be safe, but definitely not quick.

>> However, that raises the question of how to express the preferred
>> mechanism if multiple are available.  You could assume that flush-cache
>> is always preferred if available, but that's pretty clunky.
> That is how I did it in the frontend.

OK, how about this for a cheapo idea: make the
feature-barrier/flush-cache files contain a priority: 0 = "do not use",
non-zero = bigger the better?  That way we can have barrier-preferring
backends also support flush.  I suppose.

Really, frontends should also try to make do with whatever the backend
supports, even if its not preferred as well.

    J

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