Re: [PATCH v2] fuse: add inode generation number support

[Amir Goldstein]

On Tue, Sep 29, 2026 at 10:55 PM Russell Harmon <russ@xxxxxx> wrote:
>
> On Mon, Sep 28, 2026 at 9:54 AM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> >
> > On Mon, Sep 28, 2026 at 6:04 PM Russell Harmon <russ@xxxxxx> wrote:
> > >
...

> > >
> > > If I remember correctly, name_to_handle_at on a FUSE filesystem
> > > contains just the inode+generation, and open_by_handle_at results in a
> > > LOOKUP of that inode (and now inode+generation). But I'll
> > > double-check. Assuming my memory is correct, I think that's
> > > sufficient, assuming that we consider inode+generation as a unique
> > > file object identifier.
> >
> > The problem is, that what you assume is not an API definition, this is
> > a specific
> > filesystem implementation, which happens to be correct for some commonly
> > used filesystems (e.g. ext4, xfs), but is not true in general.
> > In general the API {name_to,open_by}_handle_at() the file handle is an
> > opaque blob.
>
> Maybe I'm thinking about this backwards, but we're not talking about
> "any" filesystem here. We're talking about the FUSE filesystem where
> the definition of a handle _is_ inode+generation. All I'm proposing we
> do is to expose that fact to the FUSE userspace daemon.

Correction.
The generation is exposed to userspace daemon and to the kernel
via the LOOKUP response.
All your patch does is re-validate generation in GETATTR/SETATTR.
Practically this means that generation is validated on attr expiration
time. This is a reinforcement of an incomplete id model, but it is a bandaid
not a cure.
I fail to see the real world value in this change, so please do explain it to me
in terms of use cases that would be improved and by how much.

> That daemon
> can then turn around and call open on another filesystem, or make a
> network call to AWS or whatever. In my case I want to
> open_by_handle_at on an underlying filesystem, but I can solve that by
> storing a mapping from fuse_ino+fuse_generation_num to
> underlying_fs_file_handle in my database.
>

Exactly! The daemon does not need any changes to FUSE protocol
to have a perfectly correct implementation.

If you can demonstrate or envision a filesystem that would benefit
from your patch please describe it in your proposal.

Thanks,
Amir.