Do you have a reference to back up the claim that an inode number can't be 0 in any filesystem? I couldn't find any.
–
Alok SinghalJan 20 '10 at 4:57

I guess, inode 0 has something to do with root inode of the filesystem, i am not sure? Quoted from Internet: "...the actual question is irrelevant in a business context. Inode numbers are 'opaque'. Yeah, deep down they have some secret meaning, but as long as they work, who cares. And whether 0 and 1 have a special meaning would seem extra irrelevant for production purposes, but interesting for academic research."
–
manav m-nJan 20 '10 at 5:04

4 Answers
4

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.

for instance, in old filesystems where directories were represented as a fixed array of file entries, deleting a file would result in setting that entry's inode val to 0. when traversing the directory, any entry with an inode of 0 would be ignored.

OSX specifies that inode 0 signifies a deleted file that has not yet been deleted; this may have also been used in other filesystems, as OSX is BSD-derived, although at least NetBSD seems to have now removed this usage.

When I wrote a filesystem ages ago, I used inode 0 for the .badblocks pseudo-file.

On some filesystems .badblocks is actually present in the root directory as a regular file owned by root and mode 0. root can open it but reading or writing it is undefined.

There is some ancient tradition that inodes start from 1, #1 is .badblocks, and #2 is the root directory. Even though .badblocks is not particularly well-guaranteed, many filesystems go out of their way to make root #2.