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
