Menu
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?
302
The inode number refers to the physical file, the data stored in a particular location. A file also has a device number, and the combination of its inode number and device number is unique throughout all the file systems in the hierarchical file system.
inum or I-node number is an integer associated with a file. Whenever a new file is created, a unique integer number is generated in sequence and associated with the file. This number is nothing but the pointer to the inode structure which contains the meta data of the file.
An inode is denoted by the phrase "file serial number", defined as a per-file system unique identifier for a file. That file serial number, together with the device ID of the device containing the file, uniquely identify the file within the whole system.
Usually, the inode 0 is reserved because a return value of 0 usually signals an error. Multiple method in the Linux kernel -- especially in the VFS layer shared by all file systems -- return an ino_t, e.g. find_inode_number. Other fileystems use the ino 1 as root inode number.
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.
100
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
