On Tue, 15 Mar 2011 11:11:46 +0000, Stefan Hajnoczi <stefa...@gmail.com> wrote: > On Tue, Mar 15, 2011 at 9:19 AM, Aneesh Kumar K. V > <aneesh.ku...@linux.vnet.ibm.com> wrote: > > On Mon, 14 Mar 2011 10:20:57 +0000, Stefan Hajnoczi <stefa...@gmail.com> > > wrote: > >> On Sun, Mar 13, 2011 at 7:04 PM, Aneesh Kumar K. V > >> <aneesh.ku...@linux.vnet.ibm.com> wrote: > >> > On Sun, 13 Mar 2011 17:23:50 +0000, Stefan Hajnoczi <stefa...@gmail.com> > >> > wrote: > >> >> On Sat, Mar 5, 2011 at 5:52 PM, Aneesh Kumar K.V > >> >> <aneesh.ku...@linux.vnet.ibm.com> wrote: > >> >> > cache=none implies the file are opened in the host with O_SYNC open > >> >> > flag > >> >> > >> >> O_SYNC does not bypass the host page cache. It ensures that writes > >> >> only complete once data has been written to the disk. > >> >> > >> >> O_DIRECT is a hint to bypass the host page cache when possible. > >> >> > >> >> A boolean on|off option would be nicer than an option that takes the > >> >> special string "none". For example, direct=on|off. It also makes the > >> >> code nicer by using bools instead of strdup strings that get leaked. > >> >> > >> > > >> > What i wanted is the O_SYNC behavior. Well the comment should be > >> > updated. I > >> > want to make sure that we don't have dirty data in host page cache after > >> > a write. It is always good to make read hit the page cache > >> > >> Why silently enforce O_SYNC on the server side? The client does not > >> know whether or not O_SYNC is in effect, cannot take advantage of that > >> knowledge, and cannot control it. > >> > >> I think a more useful solution is a 9p client mount option called > >> "sync" that caused the client to always add O_SYNC and skip syncfs. > >> The whole stack becomes aware of O_SYNC and clients are in control > >> over whether or not they need O_SYNC semantics. > > > > The cache=none specifically enables us to ignore the tsyncfs request on > > host. tsyncfs on host can be really slow in certain setup. > > If I'm a client with the "sync" mount option all my fids are O_SYNC > and I do not need to send TSYNCFS requests to the server because my > fids are already stable.
Having sync mount option is useful, Infact for dotu we already default O_SYNC on the client side because we don't have tsyncfs. But being able to avoid the tfsyncfs flush from the server point of view also is nice. Consider a setup where one doesn't have control on the guest mount option but can control the qemu export options. -aneesh