On Thu, Oct 21, 2021 at 9:36 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Tue, 19 Oct 2021 at 18:12, Amir Goldstein <amir73il@xxxxxxxxx> 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.
