If you are useful, it doesn't mean you are valued (betterthanrandom.substack.com)

> The root inode is the root of the file system. Inode 0 can't be used for normal purposes and historically bad blocks were linked to inode 1 (inode 1 is no longer used for this purpose; however, numerous dump tapes make this assumption, so we are stuck with it). Thus the root inode is 2.

This is also echoed on the wikipedia page for it.

The linux Kernel also has this comment for why it does not dish out that inode for shmem for instance:

> Userspace may rely on the the inode number being non-zero. For example, glibc simply ignores files with zero i_ino in unlink() and other places.

On macOS it's pretty clear that inode 0 is reserved:

> Users of getdirentries() should skip entries with d_fileno = 0, as such entries represent files which have been deleted but not yet removed from the directory entry

Animats · 3h ago

It's been a long time since what user space sees as an "inode" has anything to do with the representation within the file system.

nulld3v · 1h ago

Also, there seems to be an effort brewing in the kernel to push userspace away from depending on inode #s due to difficulty in guaranting uniqueness and stability across reboots. https://youtu.be/TNWK1zbTMOU

AndrewDavis · 1h ago

They definitely aren't unique even without reboots. Postfix uses the inode number as a queue id. At $dayjob we've seen reuse surprisingly quickly, even within a few hours. Which is a little annoying when we're log spelunking and we get two sets of results because of the repeating id!

(there is now a long queue id option which adds a time component)

amiga386 · 47m ago

...but it's unique while the file exists, right?

The combination of st_dev and st_ino from stat() should be unique on a machine, while the device remains mounted and the file continues to exist.

If the file is deleted, a different file might get the inode, and if a device is unmounted, another device might get the device id.

the_mitsuhiko · 35m ago

> The combination of st_dev and st_ino from stat() should be unique on a machine

It should, but it seems no longer to be the case. I believe there was an attempt to get a sysctl flag in to force the kernel to return the same inode for all files to see what breaks.

londons_explore · 34m ago

> ...but it's unique while the file exists, right?

I don't think all filesystems guarantee this. Especially network filesystems.

amiga386 · 13m ago

That's a problem for programs that do recursive fs descent (e.g. find, tar) because they use st_dev and st_ino alone for remembering what directories they've been in. They can't just use the absolute path, because symbolic links allow for loops.

find:

* https://cgit.git.savannah.gnu.org/cgit/findutils.git/tree/fi...

tar:

* https://cgit.git.savannah.gnu.org/cgit/tar.git/tree/src/crea...

* https://cgit.git.savannah.gnu.org/cgit/tar.git/tree/src/name...

* https://cgit.git.savannah.gnu.org/cgit/tar.git/tree/src/incr...

In particular, I'm intrigued by the comment in the last link:

      /* With NFS, the same file can have two different devices
         if an NFS directory is mounted in multiple locations,
         which is relatively common when automounting.
         To avoid spurious incremental redumping of
         directories, consider all NFS devices as equal,
         relying on the i-node to establish differences.  */

So GNU tar expects an inode to be unique across _all_ NFS mounts...

the_mitsuhiko · 29m ago

It's effectively impossible to guarantee this when you have a file system that unifies and re-exports. Network file systems being an obvious one, but overlayfs is in a similar position.

Even if inodes still work nowadays they will eventually run into issues a few years down the line.

AndrewDavis · 34m ago

Yes! It's reusable, but not duplicated.

quotemstr · 1h ago

The problem isn't relying on inode numers; it's inode numbers being too short. Make them GUIDs and the problems of uniqueness disappear. As for stability: that's just a matter of filesystem durability in general.

the_mitsuhiko · 26m ago

> The problem isn't relying on inode numers; it's inode numbers being too short.

It's a bit of both. inodes are conflating two things in a way. They are used by the file system to identify a record but they are _also_ exposed in APIs that are really cross file system (and it comes to a head in case of network file systems or overlayfs).

What's a more realistic path is to make inodes just an FS thing, let it do it's thing, and then create a set of APIs that is not relying on inodes as much. Linux for instance is trying to move towards file handles as being that API layer.