4

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?

Paulo Bu
  • 29,294
  • 6
  • 74
  • 73
Martin
  • 911
  • 7
  • 21
  • How are you going to use it? There's no user-land API that takes an inode number (and presumably a device number since only the combination is unique) and returns a file name or a file descriptor. That is reserved for the file system code in the kernel. You can be confident that if the inode number is different from before a reboot that the file has been changed. You can't be quite so confident if the inode number is the same; all you know is that the same name maps to the same number, but there might have been deletes and recreates in the interim -- the inode could have had other names too. – Jonathan Leffler Jan 14 '14 at 19:54
  • I'm primarily considering the requirements for a file system driver. Does an FS driver have the freedom to make the inode numbers up as it reads the directory tree, or will it break applications. Better yet, is there a standard and would it break expected semantics. Your comment seems to suggest that inode is a pointer for the convenience of the file system and can't really be strictly relied on for anything. ... **Would it be permitted for "ls -i" to output different inodes if the files didn't change?** – Martin Jan 14 '14 at 20:07
  • 1
    I don't know that there are necessarily any required semantics on inode numbers, but I do know that 1) not all file systems even have the notion of an inode, and so any "inode numbers" you might get from them tend to be synthetic, and 2) on most file systems, inode numbers do tend to be static, sometimes allocated and indexed at file system creation, sometimes based on the disk location where they are stored, etc. It's probably just easier that way... – twalberg Jan 14 '14 at 20:19

1 Answers1

5

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!

Paulo Bu
  • 29,294
  • 6
  • 74
  • 73
  • Do you know of an example of a file system which generates different inode numbers for the same file during a single mount session? – Martin Jan 14 '14 at 20:31
  • I can't tell for sure, but I you can try yourself. Mount a FAT32 or NTFS drive on Linux, play a little with files, doing `ls -i` after each change. Probably they won't change because they'll be cached, but they're definitely unreal. – Paulo Bu Jan 14 '14 at 20:33
  • From what I've seen, in fat and ntfs the inodes wouldn't change, they would be mapped, either the pointer to the fat, or the cluster number for ntfs. I was hoping someone has the answer and I don't need to spend weeks on playing with every single file system out there, and then discover that BSD has different semantics from Linux, or POSIX says something specific that is required, which is either not implemented or hard to observe. – Martin Jan 14 '14 at 20:38
  • None probably would change. Changing it is an expensive operation and not necessary at all. The OS probably cache it the first time and maintain it. Try to read something about VFS. – Paulo Bu Jan 14 '14 at 20:41
  • @Martin just did in Linux, `touch x`, created and inoded with `294959` id, then `rm x`, `touch y` and the inode for `y` reused the id `294959`. Does it say something? – Paulo Bu Jan 14 '14 at 20:48
  • Reusing inodes for a new file after an old file has been deleted is not the same thing as getting a different inode for the same file. Almost all inode-base file systems will re-use inodes... – twalberg Jan 14 '14 at 20:52
  • @twalberg I know, I was just trying to make a point about the `id` not being safe to use within applications. – Paulo Bu Jan 14 '14 at 20:54
  • Thank you for the experiment, but it doesn't help. I am more concerned with a file that wasn't deleted "suddenly" having a different inode number. Maybe NFS or samba, but I wouldn't expect to see that easily on a disk based FS. The question was, is it expected never to happen? – Martin Jan 14 '14 at 21:04
  • The answer I can provide you is: _With filesystems that have the notion of `inode` it's expected not to happen, with other filesystems it can happen theoretically, but you'll rarely see it_. – Paulo Bu Jan 14 '14 at 21:09