On Thu, Feb 20, 2025 at 11:26 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> On Wed, 19 Feb 2025 at 18:58, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> > I circled back to this. I don't suppose you know of any patches
> > in the works?
>
> I'm not aware of any.
>
>
> > I was thinking about LOOKUP_HANDLE in the context of our
> > discussion at Plumbers on readdirplus passthrough.
> >
> > What we discussed is that kernel could instantiate some FUSE inodes
> > (populated during readdirplus passthrough) and at some later time,
> > kernel will notify server about those inodes via FUSE_INSTANTIATE
> > or similar command, which will instantiate a fuse server inode with
> > pre-defined nodeid.
> >
> > My thinking was to simplify a bit and require a 1-to-1 mapping
> > of kernel-server inode numbers to enable the feature of
> > FUSE_PASSTHOUGH_INODE (operations), meaning that
> > every FUSE inode has at least a potential backing inode which
> > reserves its inode number.
> >
> > But I think that 1-to-1 mapping of ino is not enough and to avoid
> > races it is better to have 1-to-1 mapping of file handles so
> > FUSE_INSTANTIATE would look a bit like LOOKUP_HANDLE
> > but "found" server inode must match the kernel's file handle.
> >
> > Is any of this making any sense to you?
>
> Not yet. I remember you explaining why FUSE_INSTANTIATE is needed,
> but I don't really remember.
>
> Can you please remind me how exactly you envision readdir/lookup passthrough?
>
- readdirplus passthrough iterates on backing dir inode and populates
fuse inodes with nodeid that is taken from backing dir's children ino
(hence 1-to-1 mapping from all backing inodes to fuse ino/nodeid)
- stat()/getattr() on those children is served directly from backing inodes
- Let's call one those kernel instantiated child inodes C1
- Before any fuse command is sent to server with nodeid C1, server needs
to be notified about the entry that only the kernel knows about
- kernel could send a regular LOOKUP for the child and expect to get
a nodeid from the server that is matching C1 or mark the inode bad
Open questions:
1. Is a regular LOOKUP appropriate here or if this needs to be a new
INSTANTIATE command which tells the server about the C1 nodeid.
2. Does this need to be a LOOKUP_HANDLE command to verify that
not only the server's child has the same ino as the kernel's child but
also that they have the same file handle.
3. What is the proper API for binding a backing id to a fuse inode
regardless of readdirplus?
Extend the regular LOOKUP out args?
Require LOOKUP_HANDLE and use its out args?
4. When a child fuse inode is instantiated via readdirplus passthrough
it automatically passthrough getattr(). What about other inode ops?
are they decided only after the response of LOOKUP/INSTANTIATE?
5. Does this response need to reaffirm the binding to the backing inode
and if not, association is broken and getattr passthrough is stopped?
I have a WIP branch [1] with some of the concepts implemented.
only compile tested!
Thanks,
Amir.
[1] https://github.com/amir73il/linux/commits/fuse-backing-inode-wip/
