Re: [Xen-devel] blkfront problem in pvops kernel when barriers enabled

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Wed, Sep 07, 2011 at 11:58:38AM -0700, Jeremy Fitzhardinge wrote:
> 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.

Which it looks like we need to do. Stop the processing of the ring
buffer and do that sequence of events you mentioned. Which would
entail waiting for all of the bio callbacks to finish.

> 
> >> 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.

Well, the "older" backends could emulate the 'feature-flush-cache'
.. except it is not really right - but it will do the same thing - stop
and drain the queue (except actually flushing the contents to the disk).
So perhaps the right way to implement this in the "old" backends
is to also send SYNC along.

I think I am dense today , but the issue I am seeing is issue is with
"old" frontends (RHEL5) with "new" backends (3.0 and higher) -
where there is no 'feature-barrier' support. So they won't do barriers.

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

Sure. That is how they do it now. If it can do barriers - it will do
BLKIF_OP_BARRIER. If it can do flush, it will do BLKIF_OP_FLUSH.

Either one is used when the frontend gets REQ_FLUSH || REQ_FUA command.

> 
>     J

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