Re: blkfront problem in pvops kernel when barriers enabled

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Thu, Sep 08, 2011 at 09:06:09AM +0100, Jan Beulich wrote:
> >>> On 07.09.11 at 19:41, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >> >> <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'.
> >> > 
> >> > Indeed, I see that I added feature-flush-cache support to the frontend
> >> > back then, but neglected to do so for the backend. Partly perhaps
> >> > because I'm not much of a (block, network, ...) driver person...
> >> > 
> >> > However, what I'm not understanding with dropping feature-barrier
> >> > support from the backend - how do you deal with old frontends
> >> > wanting to use barriers? I'm currently converting them into
> > 
> > Just not supporting them. I know it is incredibly bad to do so - but
> > I have not had a chance to write the code to emulate the 'feature-barrier'
> > correctly.
> > 
> >> > WRITE_FLUSH_FUA operations in the backend as a (hopefully) best
> >> > effort approach.
> > 
> > I am not sure. I need to run blktrace|blkparse to make sure it does the
> > right think as compared to a WRITE_BARRIER. Lets ask Christopher Hellwig - he
> > knows a lot of this.
> > 
> >> 
> >> Also I notice you're using WRITE_ODIRECT - what's the background
> >> of that?
> > 
> > Ah, 
> > http://git.drbd.org/linux-2.6-drbd.git/?p=linux-2.6-drbd.git;a=commit;h=013c3 
> > ca184851078b9c04744efd4d47e52c6ecf8
> 
> Hmm, that seems more like a band-aid than a real solution. What if with
> another scheduler (or after some changes to CFQ) REQ_SYNC actually
> hurts (as - without any data - I would have expected)? Can't/shouldn't
> the use of REQ_SYNC be made at least dependent on the scheduler in
> use on the queue?

This is what the header fine says about async vs sync:

 *      All IO is handled async in Linux. This is fine for background
 *      writes, but for reads or writes that someone waits for completion
 *      on, we want to notify the block layer and IO scheduler so that they
 *      know about it. That allows them to make better scheduling
 *      decisions. So when the below references 'sync' and 'async', it
 *      is referencing this priority hint.


To make sure I was not shooting myself in the foot, I did the change and
also made sure the other schedules worked without any regressions in speeds.

But keep in mind that this 'WRITE_ODIRECT' behavior is also used
by AIO, and by any userspace application that stick O_DIRECT on the
open call. So if another another scheduler breaks this behavior we are
not the only one affected.