Re: [RFC PATCH v2 4/6] fuse: implementation of the FUSE_LOOKUP_HANDLE operation

[Luis Henriques <luis@igalia.com>]

On Wed, Dec 17 2025, Miklos Szeredi wrote:

> On Wed, 17 Dec 2025 at 10:38, Luis Henriques <luis@igalia.com> wrote:
>
>> (A question that just appeared in my mind is whether the two lookup
>> operations should be exclusive, i.e. if the kernel should explicitly avoid
>> sending a LOOKUP to a server that implements LOOKUP_HANDLE and vice-versa.
>> I _think_ the current implementation currently does this, but that was
>> mostly by accident.)
>
> Yes, I think LOOKUP_HANDLE should supersede LOOKUP.

Ack.

> Which begs the question: do we need nodeid and generation if file
> handles are used by the server?
>
> The generation is for guaranteeing uniqueness, and a file handle must
> also provide that property, so it is clearly superfluous.
>
> The nodeid is different.  It can be used as a temporary tag for easy
> lookup of a cached object (e.g. cast to a pointer).  Since it's
> temporary, it can't be embedded in the file handle.
>
> The direct cache reference can be replaced with a hash table lookup
> based on the file handle.  This would have an additional advantage,
> namely that the lifetime of objects in the user cache are not strictly
> synchronized with the kernel cache (FORGET completely omitted, or just
> a hint).

OK, this will require some more (or a lot more!) thinking from my side.
There are already several big(ish) suggestions I've started looking into,
and I need to go through them again.  Slowly ;-)

It's not clear to me at this point how to keep using nodeid+gen for
backward compatibility and replacing it by an hash table for the new
operation.  At first, it looks like a lot of code complexity will be
required for that.  But as I said, I'll need to go back and start
experimenting.

Other big change is to use fuse_ext_header instead of a variable size arg:
sounds interesting but will require more experimentation.  So, time for
going back to the drawing board!

Cheers,
-- 
Luís