[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <38a74f67-9bfc-6cb6-6999-343aac95b781@fastmail.fm>
Date: Thu, 24 Aug 2023 00:55:29 +0200
From: Bernd Schubert <bernd.schubert@...tmail.fm>
To: Jiachen Zhang <zhangjiachen.jaycee@...edance.com>,
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 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@...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?
Hi Jiachen,
isn't Miklos' idea that we can avoid writeback_cache_v2 mode?
Thanks,
Bernd
Powered by blists - more mailing lists