> >> But this does not help with persistent file handle issue for fuse > >> client. > >> > > I see. Yes that should work, but he'd still need to cope with reused > > inode numbers in case you allow unlinks from the host (do you?), > > because LOOKUP can find a host fs inode that does not match > > the file handle of a previously found inode of the same ino. > > That’s indeed an issue. My current approach is to use the file handle > (if available) as the key for lookups, so that the generation ID is > included. > > Right now, we use st_ino+st_dev+mnt_id as the key. st_dev is just a > fallback for the mount ID, basically, so what we’d really need is inode > ID + generation ID + mount ID, and that’s basically the file handle + > mount ID. So different generation IDs will lead to lookup > finding/creating a different inode object (lo_inode in C virtiofsd, > InodeData in virtiofsd-rs), and thus returning different fuse_ino IDs to > the guest. > > (See also: > https://gitlab.com/mreitz/virtiofsd-rs/-/blob/handles-for-inodes-v4/src/passthrough/mod.rs#L594) > I see, because you do not require persistent inode numbers. That makes sense if you do not need to export file handles to NFS and if you are not evicting inode objects from the server inodes map. Please keep me posted if there are any updates on LOOKUP_HANDLE. Thanks, Amir.
