Message-ID: <87zf8zp2zc.fsf@wotan.olymp>
Date: Thu, 06 Nov 2025 15:58:31 +0000
From: Luis Henriques <luis@...lia.com>
To: Amir Goldstein <amir73il@...il.com>
Cc: Bernd Schubert <bschubert@....com>,  "Darrick J. Wong"
 <djwong@...nel.org>,  Bernd Schubert <bernd@...ernd.com>,  "Theodore Ts'o"
 <tytso@....edu>,  Miklos Szeredi <miklos@...redi.hu>,
  linux-fsdevel@...r.kernel.org,  linux-kernel@...r.kernel.org,  Kevin Chen
 <kchen@....com>
Subject: Re: [RFC] Another take at restarting FUSE servers

On Thu, Nov 06 2025, Luis Henriques wrote:

> On Thu, Nov 06 2025, Amir Goldstein wrote:
>
>> [...]
>>
>>> >>> fuse_entry_out was extended once and fuse_reply_entry()
>>> >>> sends the size of the struct.
>>> >>
>>> >> Sorry, I'm confused. Where does fuse_reply_entry() send the size?
>>
>> Sorry, I meant to say that the reply size is variable.
>> The size is obviously determined at init time.
>>
>>> >>
>>> >>> However fuse_reply_create() sends it with fuse_open_out
>>> >>> appended and fuse_add_direntry_plus() does not seem to write
>>> >>> record size at all, so server and client will need to agree on the
>>> >>> size of fuse_entry_out and this would need to be backward compat.
>>> >>> If both server and client declare support for FUSE_LOOKUP_HANDLE
>>> >>> it should be fine (?).
>>> >>
>>> >> If max_handle size becomes a value in fuse_init_out, server and
>>> >> client would use it? I think appended fuse_open_out could just
>>> >> follow the dynamic actual size of the handle - code that
>>> >> serializes/deserializes the response has to look up the actual
>>> >> handle size then. For example I wouldn't know what to put in
>>> >> for any of the example/passthrough* file systems as handle size -
>>> >> would need to be 128B, but the actual size will be typically
>>> >> much smaller.
>>> >
>>> > name_to_handle_at ?
>>> >
>>> > I guess the problem here is that technically speaking filesystems could
>>> > have variable sized handles depending on the file.  Sometimes you encode
>>> > just the ino/gen of the child file, but other times you might know the
>>> > parent and put that in the handle too.
>>>
>>> Yeah, I don't think it would be reliable for *all* file systems to use
>>> name_to_handle_at on startup on some example file/directory. At least
>>> not without knowing all the details of the underlying passthrough file
>>> system.
>>>
>>
>> Maybe it's not a world-wide general solution, but it is a practical one.
>>
>> My fuse_passthrough library knows how to detect xfs and ext4 and
>> knows about the size of their file handles.
>> https://github.com/amir73il/libfuse/blob/fuse_passthrough/passthrough/fuse_passthrough.cpp#L645
>>
>> A server could optimize for max_handle_size if it knows it or use
>> MAX_HANDLE_SZ if it doesn't.
>>
>> Keep in mind that for the sake of restarting fuse servers (title of this thread)
>> file handles do not need to be the actual filesystem file handles.
>> Server can use its own pid as generation and then all inodes get
>> auto invalidated on server restart.
>>
>> Not invalidating file handles on server restart, because the file handles
>> are persistent file handles is an optimization.
>>
>> LOOKUP_HANDLE still needs to provide the inode+gen of the parent
>> which LOOKUP currently does not.
>
> One additional complication I just realised is that FUSE_LOOKUP already
> uses up all the 3 in_args.

Ok, ignore me.  We can have 4 in_args, not 3.

Cheers
-- 
Luís

> So, my initial plan of having FUSE_LOOKUP_HANDLE using a similar structure
> to FUSE_LOOKUP, with the additional parent handle passed to the server
> through the in_args needs a different solution.
>
> (Anyway, I'll need to read through the whole thread(s) again to better
> digest all the information.)
>
> Cheers,
> -- 
> Luís
>
>
>>
>> I did not understand why Darrick's suggestion of a flag that ino+gen
>> suffice is any different then max_handle_size = 12 and using the
>> standard FILEID_INO64_GEN in that case?
>>
>> Thanks,
>> Amir.

Powered by blists - more mailing lists