Nikolaus Rath wrote:
Hello, For several requests, FUSE userspace returns a struct stat to the kernel. struct stat includes an st_ino field, but FUSE generally has a separate field for the inode (e.g. fuse_entry_param.ino vs fuse_entry_param.attr.st_ino). Does the kernel use the st_ino value at all, or is just passed through to userspace?
Fuse defines its own inode number in order to track the path used to access a file. So, when a file is recorded in several directories, it is referenced by fuse with several inode numbers.
If it is just passed through, is there a need for st_ino to match the "real" inode?
There is no need. Files with several names have a single st_ino value, and a fuse inode value per path met. Unfortunately the inode numbers are used by the kernel to index the caches, and the caches for files with several inode numbers are not kept in sync (long standing issue...).
Background: Given that userspace has no use for inode values other than comparing them for equality, I would have expected that st_ino can basically be anything as long as there's some 1:1 mapping to kernel inodes. However, I have seen changes in userspace behavior when setting st_ino to the kernel inode (previously it was set to some other value by accident). Thanks! -Nikolaus
