[RFC] Optional FUSE flush-on-close

[RFC] Optional FUSE flush-on-close

[Amir Goldstein]

Miklos,

We have a use case where fuse_sync_writes() is disruptive
to the workload.

Some applications, which are not under our control do
open(O_RDONLY);fstat();close() and are made to block waiting on writes
that they are not responsible for.

Looking at other network filesystems, cifs and nfs only flush on close
for FMODE_WRITE files.
Some older SMB flavors (smb1, smb2) do also flush on RDONLY files.

In particular, our FUSE filesystem does not even implement FLUSH
and it has writeback caching disabled, so the value of flush on close
is even more questionable.

Would you be willing to consider a patch that makes flush-on-close
behavior optional for RDONLY files?
If so, should I make this option available only when filesystem
does not implement FLUSH or independent?
Should I make an option to completely disable flush-on-close
(i.e. like most disk filesystems)?

Thanks,
Amir.

Re: [RFC] Optional FUSE flush-on-close

[Miklos Szeredi]

On Tue, 19 Oct 2021 at 18:12, Amir Goldstein <amir73il@gmail.com> wrote:
>
> Miklos,
>
> We have a use case where fuse_sync_writes() is disruptive
> to the workload.
>
> Some applications, which are not under our control do
> open(O_RDONLY);fstat();close() and are made to block waiting on writes
> that they are not responsible for.
>
> Looking at other network filesystems, cifs and nfs only flush on close
> for FMODE_WRITE files.
> Some older SMB flavors (smb1, smb2) do also flush on RDONLY files.
>
> In particular, our FUSE filesystem does not even implement FLUSH
> and it has writeback caching disabled, so the value of flush on close
> is even more questionable.
>
> Would you be willing to consider a patch that makes flush-on-close
> behavior optional for RDONLY files?
> If so, should I make this option available only when filesystem
> does not implement FLUSH or independent?
> Should I make an option to completely disable flush-on-close
> (i.e. like most disk filesystems)?

Flushing dirty pages for writable files  is mandatory for the
writeback cache case.  Otherwise you are correct, this could be
disabled.

How about FOPEN_NOFLUSH?

Thanks,
Miklos

>
> Thanks,
> Amir.

Re: [RFC] Optional FUSE flush-on-close

[Amir Goldstein]

On Thu, Oct 21, 2021 at 9:36 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Tue, 19 Oct 2021 at 18:12, Amir Goldstein <amir73il@gmail.com> wrote:
> >
> > Miklos,
> >
> > We have a use case where fuse_sync_writes() is disruptive
> > to the workload.
> >
> > Some applications, which are not under our control do
> > open(O_RDONLY);fstat();close() and are made to block waiting on writes
> > that they are not responsible for.
> >
> > Looking at other network filesystems, cifs and nfs only flush on close
> > for FMODE_WRITE files.
> > Some older SMB flavors (smb1, smb2) do also flush on RDONLY files.
> >
> > In particular, our FUSE filesystem does not even implement FLUSH
> > and it has writeback caching disabled, so the value of flush on close
> > is even more questionable.
> >
> > Would you be willing to consider a patch that makes flush-on-close
> > behavior optional for RDONLY files?
> > If so, should I make this option available only when filesystem
> > does not implement FLUSH or independent?
> > Should I make an option to completely disable flush-on-close
> > (i.e. like most disk filesystems)?
>
> Flushing dirty pages for writable files  is mandatory for the
> writeback cache case.  Otherwise you are correct, this could be
> disabled.
>
> How about FOPEN_NOFLUSH?
>

Sounds good to me.

BTW, regardless of $SUBJECT, I've learned that cifs_flush() behaves a bit
differently than nfs_file_flush().

cifs_flush() flushes the local caches, but does not issue a flush command to
the server while nfs_file_flush() also sends/waits for a commit
request to the server.

IIUC, nfs4_file_flush() behaves like nfs_file_flush() if the client
holds a write
delegation (i.e. like writeback caching) and like cifs_flush() without
write delegation.

I am guessing this is all intentional (?) but it makes me wonder because this
logic mixes cache coherency considerations with durability considerations.
IOW, I am not sure why nfs server will end up fsyncing the file on server
on nfs client close and smb server will not.

Thanks,
Amir.