I’m planning to implement a FUSE filesystem using low-level API and currently trying to understand the fuse_entry_param structure.
I wonder what unsigned long fuse_entry_param::generation actually means. Documentation says just that ino/generation pair should be unique for the filesystem’s lifetime, but does not go into any details.
What’s the semantics of inode generations and how they are used?
For example, can I just consider generation as an additional bit of ino (like some sort of namespace) and use them freely to map arbitrary lifetime-unique 128-bit (2*sizeof(unsigned long) on x86_64) values to inodes? Or are generations meant to be only incremented sequentially? What happens when inode numbers collide, but their generation numbers differ?
The ‘generation’ field is important if your inode number generator may generate different inode numbers at different times for the same object. This is uncommon for on-disk file systems, but it may happen for network file systems (like NFS, see 1).
It is mentioned in 1 that a server may use a different set of (fuse) inode numbers/(nfs) file handles after a restart. If that happens, it is possible that the new inode numbers map to objects in a different way then the inode numbers which were given out before the server restart.
A client could use a different generation number for the set of inodes before the restart and for the set of inodes after the restart to make clear which inode is meant.
If your file system has a static generation scheme for inodes (where an inode number always points to the same object), there is no need to use the generation number and it may be used to extend the inode number.