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 11:58:38 -0700 Message-ID: <4E67BEDE.6080301@goop.org> References: <4E6357C6.6050101@mimuw.edu.pl> <20110906163213.GC5264@dumpdata.com> <4E665572.7080009@mimuw.edu.pl> <20110907014741.GD30639@dumpdata.com> <4E67AB39.70801@goop.org> <20110907174314.GM32190@dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110907174314.GM32190@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/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. >>> >>> >>> 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