Message-ID: <874ir7qjov.fsf@wotan.olymp>
Date: Thu, 06 Nov 2025 15:12:16 +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, 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.

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