qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH] sheepdog: implement direct write semantics
Date: Tue, 08 Jan 2013 13:12:49 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0

Am 08.01.2013 12:35, schrieb Liu Yuan:
> 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.

Ok, thanks. It would be good if it was before the hard freeze for 1.4.

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

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]