On Thu, 20 Feb 2025 at 16:51, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > - 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) If nodeid == st_ino, then in theory no LOOKUP is needed, the kernel can just assume that the fuse server can look up the object based on st_ino. The problem with that is: looking up by st_ino can only be done by doing a complete scan of the filesystem, which is often not practical. > - 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 A regular LOOKUP assumes that the parent is already known by the server. Of course, this could be done recursively up to the fs root, but it looks really tricky due to locking assumptions. > > 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. How would this INSTANTIATE work? Telling the server about the nodeid won't help, it has the same problems as if the server was just using the nodeid (st_ino) directly. > 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. Hmm, you mean the kernel queries the backing inode's fh, then sends a LOOKUP_HANDLE with that fh? I guess that might work. > 3. What is the proper API for binding a backing id to a fuse inode > regardless of readdirplus? > Extend the regular LOOKUP out args? Yes, this is how I'd imagine this (which doesn't mean it's the best option). > 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 don't know. It would be good to see what this will be used for. > > I have a WIP branch [1] with some of the concepts implemented. > only compile tested! Will have a look... Thanks, Miklos
