quoted

quoted

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.