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: Liu Yuan
Subject: Re: [Qemu-devel] [PATCH] sheepdog: implement direct write semantics
Date: Thu, 10 Jan 2013 13:38:16 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 01/09/2013 11:10 PM, Paolo Bonzini wrote:
> Il 09/01/2013 14:04, Liu Yuan ha scritto:
>>>>   2 The upper layer software which relies on the 'cache=xxx' to choose
>>>> cache mode will fail its assumption against new QEMU.
>>>
>>> Which assumptions do you mean? As far as I can say the behaviour hasn't
>>> changed, except possibly for the performance.
>>
>> When users set 'cache=writethrough' to export only a writethrough cache
>> to Guest, but with new QEMU, it will actually get a writeback cache as
>> default.
> 
> They get a writeback cache implementation-wise, but they get a
> writethrough cache safety-wise.  How the cache is implemented doesn't
> matter, as long as it "looks like" a writethrough cache.
> 

> In fact, consider a local disk that doesn't support FUA.  In old QEMU,
> images used to be opened with O_DSYNC and that splits each write into
> WRITE+FLUSH, just like new QEMU.  All that changes is _where_ the
> flushes are created.  Old QEMU changes it in the kernel, new QEMU
> changes it in userspace.
> 
>> We don't need to communicate to the guest. I think 'cache=xxx' means
>> what kind of cache the users *expect* to export to Guest OS. So if
>> cache=writethrough set, Guest OS couldn't turn it to writeback cache
>> magically. This is like I bought a disk with 'writethrough' cache
>> built-in, I didn't expect that it turned to be a disk with writeback
>> cache under the hood which could possible lose data when power outage
>> happened.
> 
> It's not by magic.  It's by explicitly requesting the disk to do this.
> 
> Perhaps it's a bug that the cache mode is not reset when the machine is
> reset.  I haven't checked that, but it would be a valid complaint.
> 

Ah I didn't get the current implementation right. I tried the 3.7 kernel
and it works as expected (cache=writethrough result in a 'writethrough'
cache in the guest).

It looks fine to me to emulate writethrough as writeback + flush, since
the profermance drop isn't big, though sheepdog itself support true
writethrough cache (no flush).

I am going to send v2 of directio patch for sheepdog driver.

Thanks,
Yuan



reply via email to

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