From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: blkfront problem in pvops kernel when barriers enabled Date: Wed, 7 Sep 2011 13:43:14 -0400 Message-ID: <20110907174314.GM32190@dumpdata.com> References: <4E6357C6.6050101@mimuw.edu.pl> <20110906163213.GC5264@dumpdata.com> <4E665572.7080009@mimuw.edu.pl> <20110907014741.GD30639@dumpdata.com> <4E67AB39.70801@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <4E67AB39.70801@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: "xen-devel@lists.xensource.com" , Marek Marczykowski List-Id: xen-devel@lists.xenproject.org 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. > > > > > > 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. > > 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. > > J