Re: [Qemu-devel] [PATCH] sheepdog: implement direct write semantics

[Liu Yuan <namei.unix@gmail.com>]

On 01/08/2013 07:19 PM, Kevin Wolf wrote:
> I can't see a reason why it would do that. Can you bisect this?
> 

Sure, bisect it is on my schedule, but I can't promise a deadline.

>>>> >>> It seems it is hard to restore into old semantics of cache flags due to
>>>> >>> new design of QEMU block layer. So will you accept that adding a 'flags'
>>>> >>> into BlockDriverState which carry the 'cache flags' from user to keep
>>>> >>> backward compatibility?
>>> >>
>>> >> No, going back to the old behaviour would break guest-toggled WCE.
>>> >>
>> > 
>> > Guest-toggled WCE only works with IDE and seems that virtio-blk doesn't
>> > support it, no? And I think there are huge virtio-blk users.
> It works with virtio-blk and SCSI as well.
> 

Okay, I see the code indeed support WCE but it requires Guest kernel to
support it. For the kernel doesn't support it, there is no way to
disable write cache, no?

>> > I didn't meant to break WCE. What I meant is to allow backward
>> > compatibility. For e.g, Sheepdog driver can make use of this dedicated
>> > cache flags to implement its own cache control and doesn't affect other
>> > drivers at all.
> How would you do it? With a WCE that changes during runtime the idea of
> a flag that is passed to bdrv_open() and stays valid as long as the
> BlockDriverState exists doesn't match reality any more.

I am not sure if I get it right. What I meant is allow Sheepdog to
control cache on the 'cache flags' at startup and ignore WCE on the run
time.

So you mean, if I choose witeback cache at startup, and then Guest
disable it via WCE, then block layer will never send flush request down
to Sheepdog driver?

Thanks,
Yuan