Christoph Hellwig wrote: > On Mon, Mar 08, 2010 at 09:47:32AM +0000, Jamie Lokier wrote: > > Assuming the outcome is that it becomes a qdev property, and stays > > preserved across migrations, even if the backing device access > > changes, then I think the right thing is to dynamically decide to set > > O_DSYNC and/or call fdatasync before completing writes from qemu when > > the guest thinks enable_write_cache=0 (or sets it to 0). With > > cache=none, that would set O_DSYNC|O_DIRECT if the two flags do work > > properly together on our favourite hosts. > > > > Thus enable_write_cache won't always have the default value for the > > different backing device access type, but it will match the guest's > > expectations and be actually safe. Moreover more, by responding to > > the guest changing that, it's closer to behaving like real harware. > > I'd have to look at other uses of qdev, but I would assume that we > always look at the qdev properties and only use the existing drive > suboptions as compatiblity if we do not have the qdev properties set.
I'm not sure if I was clear or not: I mean if the guest runs "hdparm -W $value" or Windows equivalent, and cache!=writethrough, it should have the effect of turning on/off the host's O_DSYNC flag (or qemu calling fdatasync() before signalling every write completion), because that's really just another way for the guest say it wants to flush write caches after every write. So that's what the emulation should do, either explicitly (fdatasync) or a subtler way (O_DSYNC). That guest-visible flag, which is part of the emulated drive state, should be preserved across migration. -- Jamie
