Re: [Qemu-devel] [PATCH -V3 7/8] hw/9pfs: Add new virtfs option cache=none to skip host page cache

[Stefan Hajnoczi]

On Tue, Mar 15, 2011 at 12:30 PM, Aneesh Kumar K. V
<address@hidden> wrote:
> On Tue, 15 Mar 2011 11:11:46 +0000, Stefan Hajnoczi <address@hidden> wrote:
>> On Tue, Mar 15, 2011 at 9:19 AM, Aneesh Kumar K. V
>> <address@hidden> wrote:
>> > On Mon, 14 Mar 2011 10:20:57 +0000, Stefan Hajnoczi <address@hidden> wrote:
>> >> On Sun, Mar 13, 2011 at 7:04 PM, Aneesh Kumar K. V
>> >> <address@hidden> wrote:
>> >> > On Sun, 13 Mar 2011 17:23:50 +0000, Stefan Hajnoczi <address@hidden> 
>> >> > wrote:
>> >> >> On Sat, Mar 5, 2011 at 5:52 PM, Aneesh Kumar K.V
>> >> >> <address@hidden> 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.

If the guest mount is sync it should not send syncfs because all its
files are opened O_SYNC and do not need syncing.  Toggling this option
on the host side has no effect either way.

If the guest mount is not sync then setting the option on the host
side overrides the guest and forces O_SYNC.  The result will likely be
slower writes but nop syncfs.

In both cases, the guest (and the application) is where O_SYNC matters
from a data integrity perspective.  The guest always has control over
whether it opens files with O_SYNC.

So this host side control only enables you to force O_SYNC when the
guest doesn't expect it, which does not seem like a useful feature to
me.  What does this buy us?

Stefan