linux-kernel - Re: [PATCH 4/5] fuse: writeback_cache consistency enhancement (writeback_cache

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <029cb695-9b8e-8fb3-ef0f-b223f34e7639@bytedance.com>
Date:   Wed, 23 Aug 2023 18:59:49 +0800
From:   Jiachen Zhang <zhangjiachen.jaycee@...edance.com>
To:     Bernd Schubert <bernd.schubert@...tmail.fm>,
        Miklos Szeredi <miklos@...redi.hu>
Cc:     Jonathan Corbet <corbet@....net>, linux-fsdevel@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        me@...x.top
Subject: Re: [PATCH 4/5] fuse: writeback_cache consistency enhancement
 (writeback_cache_v2)

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

Thanks,
Jiachen