[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <699673a6-ff82-8968-6310-9a0b1c429be3@fastmail.fm>
Date: Wed, 23 Aug 2023 12:35:44 +0200
From: Bernd Schubert <bernd.schubert@...tmail.fm>
To: Miklos Szeredi <miklos@...redi.hu>,
Jiachen Zhang <zhangjiachen.jaycee@...edance.com>
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 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
Powered by blists - more mailing lists