Message-ID: <20251106154940.GF196391@frogsfrogsfrogs>
Date: Thu, 6 Nov 2025 07:49:40 -0800
From: "Darrick J. Wong" <djwong@...nel.org>
To: Amir Goldstein <amir73il@...il.com>
Cc: Bernd Schubert <bschubert@....com>, Luis Henriques <luis@...lia.com>,
	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 at 11:13:01AM +0100, 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.
> 
> 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?

Technically speaking, a 12-byte handle could contain anything.  Maybe
you have a u32 volumeid, inumber, and generation, whereas the flag that
I was mumbling about would specify the handle format as well.

Speaking of which: should file handles be exporting volume ids for the
filesystem (btrfs) that supports it?

--D

> Thanks,
> Amir.

Powered by blists - more mailing lists