Re: Re: [RFC PATCH v2 6/6] fuse: implementation of export_operations with FUSE_LOOKUP_HANDLE

[Horst Birthelmer]

On Wed, Dec 17, 2025 at 05:02:59PM +0000, Luis Henriques wrote:
> On Tue, Dec 16 2025, Horst Birthelmer wrote:
> 
> > On Tue, Dec 16, 2025 at 05:06:25PM +0000, Luis Henriques wrote:
> >> On Tue, Dec 16 2025, Miklos Szeredi wrote:
> > ...
> >> >
> >> > I think it should be either
> >> >
> >> >   - encode nodeid + generation (backward compatibility),
> >> >
> >> >   - or encode file handle for servers that support it
> >> >
> >> > but not both.
> >> 
> >> OK, in fact v1 was trying to do something like that, by defining the
> >> handle with this:
> >> 
> >> struct fuse_inode_handle {
> >> 	u32 type;
> >> 	union {
> >> 		struct {
> >> 			u64 nodeid;
> >> 			u32 generation;
> >> 		};
> >> 		struct fuse_file_handle fh;
> >> 	};
> >> };
> >> 
> >> (The 'type' is likely to be useless, as we know if the server supports fh
> >> or not.)
> >> 
> >> > Which means that fuse_iget() must be able to search the cache based on
> >> > the handle as well, but that should not be too difficult to implement
> >> > (need to hash the file handle).
> >> 
> >> Right, I didn't got that far in v1.  I'll see what I can come up to.
> >> Doing memcmp()s would definitely be too expensive, so using hashes is the
> >> only way I guess.
> >> 
> > Please excuse my ignorance, but why would memcmp() be too expensive for a proof of concept?
> > Inode handles are limited and the cache is somewhat limited.
> 
> (Oops, looks like I missed your email.)

Don't worry about it.

> So, if every time we're looking for a file handle we need to memcmp() it
> with all the handles until we find it (or not!), that would easily be very
> expensive if we have a lot of handles cached.  That's what I meant in my
> reply, comparing this with an hash-based lookup.

I get all that. My point was more of a suggestion to not worry too much about
that comparison, since the data size is really limited.
If you know and/or have figured out all the rest, you can think about what exactly
to hash if necessary.

BTW, I really liked your approach, that's why I said that. 
It was more of a general comment than a technical one.

> 
> (Not sure I answered your question, as I may have also misunderstood
> Miklos suggestions.  It happens quite often!  Just read my replies in this
> patchset :-) )
I have read the replies ;-)

Cheers,
Horst