Re: [PATCH 4/5] fuse: writeback_cache consistency enhancement (writeback_cache_v2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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.


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?

Thanks,
Jiachen





[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux