Re: blkfront problem in pvops kernel when barriers enabled

[Jeremy Fitzhardinge <jeremy@goop.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.
>>> <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