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

[Luis Henriques <luis@igalia.com>]

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.)

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.

(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 :-) )

Cheers,
-- 
Luís