Messages in this thread | | | Date | Thu, 24 Aug 2023 00:55:29 +0200 | Subject | Re: [PATCH 4/5] fuse: writeback_cache consistency enhancement (writeback_cache_v2) | From | Bernd Schubert <> |
| |
On 8/23/23 12:59, Jiachen Zhang wrote: > On 2023/8/23 18:35, Bernd Schubert wrote: >> On 8/23/23 11:07, Miklos Szeredi wrote: >>> On Tue, 11 Jul 2023 at 06:36, Jiachen Zhang >>> <zhangjiachen.jaycee@bytedance.com> 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. >> >> >> I think it would be good to have flush-on-getattr configurable - >> systems with a distributed lock manager (DLM) and notifications from >> server/daemon to kernel should not need it. >> >> >> Thanks, >> Bernd > > Hi Miklos and Bernd, > > I agree that flush-on-getattr is a good solution to keep the c/mtime > consistency for the view of userspace applications. > > Maybe in the next version, we can add the flush-on-getattr just for the > writeback_cache_v2 mode, as daemons replying on reverse notifications > are likely not need the writeback_cache_v2 mode. What do you think?
Hi Jiachen,
isn't Miklos' idea that we can avoid writeback_cache_v2 mode?
Thanks, Bernd
| |