From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: blkfront problem in pvops kernel when barriers enabled Date: Wed, 07 Sep 2011 10:34:49 -0700 Message-ID: <4E67AB39.70801@goop.org> References: <4E6357C6.6050101@mimuw.edu.pl> <20110906163213.GC5264@dumpdata.com> <4E665572.7080009@mimuw.edu.pl> <20110907014741.GD30639@dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110907014741.GD30639@dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Konrad Rzeszutek Wilk Cc: "xen-devel@lists.xensource.com" , Marek Marczykowski List-Id: xen-devel@lists.xenproject.org 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 even if the backend would prefer flush-cache, it should also advertise barriers. 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. J