| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] blkfront problem in pvops kernel when barriers enabled
>>> On 07.09.11 at 19:41, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 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?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home