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

[Liu Yuan]

On 01/08/2013 08:12 PM, Kevin Wolf wrote:
> Ok, thanks. It would be good if it was before the hard freeze for 1.4.
> 

Oops, sorry. It is a false alarm. Last time I was running latest QEMU on
tmpfs which service the request too fast.

>>>>>>>>> >>>>>>>> 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?
> With Linux guests, it's possible for SCSI. I'm not sure about
> virtio-blk, but you might be right that you can't manually change it there.
> 
>>>>> >>>> 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.
> If you start with cache=writeback and then the guests switches WCE off
> and you ignore that, then you're causing data corruption in the case of
> a crash. This is not an option.
> 
>> > 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?
> Yes, this is the problematic case. Currently the qemu block layer makes
> sure to send flushes, but if you disable that logic for Sheepdog, you
> would get broken behaviour in this case.

Maybe not for a second thought. See following combination:

   cache flags            WCE toggled and resulting behavior
   writethrough           writethrough
   writeback              writetrhough (writeback + flush as expected)

cache flags means specify 'cache=xxx' at startup and WCE toggled on the
fly in the guest (supose guest kernel support WCE control)

So the result is *not* broken. If we set cache=writethrough for
sheepdog, then WCE won't take any effect because 'flush' request will be
ignored by Sheepdog driver. And with cache=writeback, WCE does disable
the writecache and actually turns it to a writethrough cache by sending
flush req every time for write.

To conclude, let Sheepdog interpret cache flags won't cause trouble even
with current Guest WCE feature, the different is that if we set
cache=writethrough, guest can't change it via WCE toggling. Is this
behavior acceptable?

Thanks,
Yuan