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

[Jamie Lokier]

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.

The question is, is cache=writeback/cache=writethrough an initial
setting of guest-visible WCE that the guest is allowed to change, or
is cache=writeththrough a way of saying "don't have a write cache"
(which may or may not be reflected in the guest-visible disk id).

I couldn't tell from QEMU documentation which is intended.  It would
be a bit silly if it means different things for different backend
storage.

I have seen (obscure) guest code which toggled WCE to simulate FUA,
and there is plenty of advice out there saying to set WCE=0 for
certain kinds of databases because of its presumed crash safety.  Even
very ancient guests on Linux and Windows can change WCE=0 with IDE and
SCSI.

So from a guest point of view, I think guest setting WCE=0 should mean
exactly the same as FUA every write, or flush after every write, until
guest setting WCE=1.

-- Jamie