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: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH] sheepdog: implement direct write semantics
Date: Wed, 09 Jan 2013 16:10:32 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

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.

Paolo

> 
> So Guest-WCE only works when users provide us a writeback capable disk.




reply via email to

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