On Tue, 11 Jul 2023 at 06:36, Jiachen Zhang <zhangjiachen.jaycee@xxxxxxxxxxxxx> wrote: > > Some users may want both the high performance of the writeback_cahe mode > and a little bit more consistency among FUSE mounts. Current > writeback_cache mode never updates attributes from server, so can never > see the file attributes changed by other FUSE mounts, which means > 'zero-consisteny'. > > This commit introduces writeback_cache_v2 mode, which allows the attributes > to be updated from server to kernel when the inode is clean and no > writeback is in-progressing. FUSE daemons can select this mode by the > FUSE_WRITEBACK_CACHE_V2 init flag. > > In writeback_cache_v2 mode, the server generates official attributes. > Therefore, > > 1. For the cmtime, the cmtime generated by kernel are just temporary > values that are never flushed to server by fuse_write_inode(), and they > could be eventually updated by the official server cmtime. The > mtime-based revalidation of the fc->auto_inval_data mode is also > skipped, as the kernel-generated temporary cmtime are likely not equal > to the offical server cmtime. > > 2. For the file size, we expect server updates its file size on > FUSE_WRITEs. So we increase fi->attr_version in fuse_writepage_end() to > check the staleness of the returning file size. > > Together with FOPEN_INVAL_ATTR, a FUSE daemon is able to implement > close-to-open (CTO) consistency like NFS client implementations. What I'd prefer is mode similar to NFS: getattr flushes pending writes so that server ctime/mtime are always in sync with client. FUSE probably should have done that from the beginning, but at that time I wasn't aware of the NFS solution. Thanks, Miklos
