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

[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@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?

Hi Jiachen,

isn't Miklos' idea that we can avoid writeback_cache_v2 mode?


Thanks,
Bernd