On Sun, Oct 9, 2011 at 4:34 PM, Aneesh Kumar K.V <aneesh.ku...@linux.vnet.ibm.com> wrote: > On Sat, 8 Oct 2011 12:24:37 +0100, Stefan Hajnoczi <stefa...@gmail.com> wrote: >> On Fri, Oct 7, 2011 at 7:46 AM, Aneesh Kumar K.V >> <aneesh.ku...@linux.vnet.ibm.com> wrote: >> > cache=writethrough implies the file are opened in the host with O_SYNC >> > open flag >> > >> > Signed-off-by: Aneesh Kumar K.V <aneesh.ku...@linux.vnet.ibm.com> >> > --- >> > fsdev/file-op-9p.h | 1 + >> > fsdev/qemu-fsdev.c | 10 ++++++++-- >> > fsdev/qemu-fsdev.h | 2 ++ >> > hw/9pfs/virtio-9p-device.c | 5 +++++ >> > hw/9pfs/virtio-9p.c | 24 ++++++++++++++++++------ >> > qemu-config.c | 6 ++++++ >> > qemu-options.hx | 17 ++++++++++++----- >> > vl.c | 6 ++++++ >> > 8 files changed, 58 insertions(+), 13 deletions(-) >> >> When would this be used? For serving up vanilla 9P? >> >> I think 9P.u and 9P.l have support for fsync(2) while vanilla 9P does not. >> > > TFSYNC is added by 9p.L. So we would need this for 9p.u.
I think 9p.u is covered by this wstat hack in http://ericvh.github.com/9p-rfc/rfc9p2000.html#anchor32: "if all the elements of the directory entry in a Twstat message are ``don't touch'' val- ues, the server may interpret it as a request to guarantee that the contents of the associated file are committed to stable storage before the Rwstat message is returned." A real TFSYNC operation is nicer though and could be mandatory (the 9P2000 RFC only says "the server *may*"). > Another use > case is to ensure that we don't leave pages on host as dirty. That would > ensure that large writeback from a guest don't result in large number of > dirty pages on the host, thereby resulting in writeback in the host. It > would be needed for predictable I/O behavior in a setup where we have > multiple guest. I see. I'm mostly curious about this change because the caching modes are a nightmare with block devices - a lot of time is spent discussing and benchmarking them, and they cause confusion when configuring KVM. It sounds like O_SYNC is being used in order to keep page cache clean. But keeping the page cache clean is a side-effect of O_SYNC's behavior: writing out each page and synchronizing the disk write cache. If you are attempting to bypass the page cache, just use O_DIRECT without O_SYNC. O_SYNC is doing the additional disk write cache synchronization which will slow down I/O and prevent the server from using disk write cache. O_SYNC is not the right flag to use. Stefan
