CODEWITHSUNDEEP
linuxunixfilesystemsposixinode
Martin
Martin

Reputation: 923

Inode number after reboot

Is the inode number guaranteed (e.g. by a standard) to be the same after a reboot, a remount or even after it was closed by all processes and then opened again? E.g. can it be automatically generated when a file is opened as opposed to being stored on the file system. Can an application rely on it? Does a file system implementation need to guarantee specific semantics?

Upvotes: 4

Views: 2016

Answers (1)

Paulo Bu
Paulo Bu

Reputation: 29804

inode is not a general concept for every filesystems. Ext filesystem and the Linux VFS sees an inode as a data structure that stores information about a file. But, for example, FAT32 or NTFS don't have idea of what an inode is because they simply don't use that concept.

Having said this, I'll try to give answers to your questions:

Is the inode number guaranteed (e.g. by a standard) to be the same after a reboot, a remount or even after it was closed by all processes and then opened again?

Depends, if the filesystem is of Ext kind, then the inode number is stored in the i_ino file inside struct inode, which is written to disk, so yes, in this case if the file is the same (not other file with the same name) then the inode number is guaranteed to be the same.

Otherwise if the file system is other than Ext, the inode number is generated by the inode operations defined by the filesystem driver, as they don't have the concept of what an inode is, they have to mimic all inode's internal fields to comply with VFS, so this number will probably be different after reboot, even after closing and opening the file again perhaps (theoretically).

E.g. can it be automatically generated when a file is opened as opposed to being stored on the file system.

Yes! Non Ext filesystem's drivers (FAT32, NTFS) generate an inode structure whenever one of its file is accessed.

Can an application rely on it?

Not very safe, applications rely on file paths, which are more human readable. Having to find a file by its inode will mean to loop through all the inodes in a partition (many many). By resolving the file's path, the search is optimized, it only checks files within directories.

Does a file system implementation need to guarantee specific semantics?

I don't understand quite well this question but I assume yes, filesystems are very complicated structures, they need to establish well what data types it'll need and what will be their meaning.

For example: Ext defines block, inode and dentry as well as a list of functions over these data structures.

Hope this helps!

Upvotes: 6

Related Questions