Re: [PATCH v2 12/21] fuse: add struct fuse_entry2_out and helpers for extended entry replies
Amir Goldstein <[email protected]> Sat, 16 May 2026 19:25:05 +0200
| Newsgroups | org.kernel.vger.linux-unionfs,dev.linux.lists.fuse-devel |
|---|---|
| Message-ID | <CAOQ4uxjMPPp-R37yKoOs1kGUdAOmnp3keVWvfuxi1r8jrxAcTA@mail.gmail.com> |
On Sat, May 16, 2026 at 2:52 AM Joanne Koong <[email protected]> wrote: > > Add struct fuse_entry2_out, which is a new extended entry reply struct > that carries a backing_id and statx attributes. This will be necessary > for setting fuse passthrough on inodes. > > Add helpers that subsequent commits will use to process fuse_entry2_out > for passthrough support for lookup, revalidate, and create. > fuse_statx_to_attr() is also moved to earlier in the file to avoid > forward declaring. > I think you had a discussion with Miklos about whether it makes sense to do a compound response for LOOKUP+STATX. I don't remember the conclusion, but if this can save us all the if (use_entry2) { } else {} all over the code, then I think it is worth it. Can you give me the bottom line from your discussion or was there no conclusion reached? If we do that, where do we return backing_id? Could make use of the reserved[] fields in fuse_statx_out. I happen to have a test patch at the tip of my fuse-backing-inode-wip branch: 6e296625eafd6 fuse: support setting backing inode passthrough on getattr It's not using the statx response, and it was just done for testing, but in theory, if a server wants to change an inode from non-passthrough to yes-passthrough mid lifetime doing this on attribute cache expiry may make more sense than on entry timeout expiry, because backing_id is an attribute of the inode not the dentry. Not sure if this is making any sense. Thanks, Amir.