On Sun, Oct 24, 2021 at 6:17 PM Shachar Sharon <synarete@xxxxxxxxx> wrote: > > On Sun, Oct 24, 2021 at 05:21:55PM +0300, Amir Goldstein wrote: > >On Sun, Oct 24, 2021 at 4:55 PM Shachar Sharon <synarete@xxxxxxxxx> wrote: > >> > >> On Sun, Oct 24, 2021 at 04:26:07PM +0300, Amir Goldstein wrote: > >> >Add flag returned by OPENDIR request to avoid flushing data cache > >> >on close. > >> > > >> I believe this holds not only for FUSE_OPENDIR but also to FUSE_OPEN and > >> FUSE_CREATE (see 'struct fuse_open_out'). > >> > > > >Oops that was a copy&paste typo. > >Of course this is only relevant for FUSE_OPEN and FUSE_CREATE. > IMHO it is relevant to all 3 cases (FUSE_OPEN, FUSE_CREATE, > FUSE_OPENDIR). > fuse_dir_operations have no ->flush() as there is no write cache for directories. > > > > >> >Different filesystems implement ->flush() is different ways: > >> >- Most disk filesystems do not implement ->flush() at all > >> >- Some network filesystem (e.g. nfs) flush local write cache of > >> > FMODE_WRITE file and send a "flush" command to server > >> >- Some network filesystem (e.g. cifs) flush local write cache of > >> > FMODE_WRITE file without sending an additional command to server > >> > > >> >FUSE flushes local write cache of ANY file, even non FMODE_WRITE > >> >and sends a "flush" command to server (if server implements it). > >> > > >> >The FUSE implementation of ->flush() seems over agressive and > >> >arbitrary and does not make a lot of sense when writeback caching is > >> >disabled. > >> > > >> >Instead of deciding on another arbitrary implementation that makes > >> >sense, leave the choice of per-file flush behavior in the hands of > >> >the server. > >> > > >> >Link: https://lore.kernel.org/linux-fsdevel/CAJfpegspE8e6aKd47uZtSYX8Y-1e1FWS0VL0DH2Skb9gQP5RJQ@xxxxxxxxxxxxxx/ > >> >Suggested-by: Miklos Szeredi <mszeredi@xxxxxxxxxx> > >> >Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> > >> >--- > >> > > >> >Hi Miklos, > >> > > >> >I've tested this manually by watching --debug-fuse prints > >> >with and without --nocache option to passthrough_hp. > >> > > >> >The libfuse+passthrough_hp patch is at: > >> >https://github.com/amir73il/libfuse/commits/fopen_noflush > >> > > >> >Thanks, > >> >Amir. > >> > > >> > fs/fuse/file.c | 3 +++ > >> > include/uapi/linux/fuse.h | 3 +++ > >> > 2 files changed, 6 insertions(+) > >> > > >> >diff --git a/fs/fuse/file.c b/fs/fuse/file.c > >> >index 11404f8c21c7..6f502a76f9ac 100644 > >> >--- a/fs/fuse/file.c > >> >+++ b/fs/fuse/file.c > >> >@@ -483,6 +483,9 @@ static int fuse_flush(struct file *file, fl_owner_t id) > >> > if (fuse_is_bad(inode)) > >> > return -EIO; > >> > > >> >+ if (ff->open_flags & FOPEN_NOFLUSH) > >> >+ return 0; > >> >+ > >> > err = write_inode_now(inode, 1); > >> > if (err) > >> > return err; > >> >diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h > >> >index 36ed092227fa..383781d1878f 100644 > >> >--- a/include/uapi/linux/fuse.h > >> >+++ b/include/uapi/linux/fuse.h > >> >@@ -184,6 +184,7 @@ > >> > * > >> > * 7.34 > >> > * - add FUSE_SYNCFS > >> Most likely you want to bump to 7.35; 7.34 is already out in the wild > >> (e.g., on my Fedora33 workstation) > >> > > > >Possibly. I wasn't sure what was the rationale behind when the version > >should be bumped. > >One argument against bumping the version is that there is not much > >harm is passing this flag to an old kernel - it just ignored the flag > >and sends the flush requests anyway. Miklos, do I need to bump the protocol version? Thanks, Amir.
