What are inodes good for?

Question

I wonder if storing the information about files in inodes instead of directly in the directory is worth the additional overhead. It may be well that I'm overestimating the overhead or overlooking some important thing, but that's why I'm asking.

I see that something like "inodes" is necessary for hardlinks, but in case the overhead is really as big as I think, I wonder if any of the reasons justifies it:

• using hardlinks for backups is clever, but efficiency of backups is not important enough when compared to the efficiency of normal operations
• having neither speed nor size penalty for hardlinks can really matter, as this advantage holds only for the few files making use of hardlinks while the access to all files suffers the overhead
• saving some space for a couple of equally named binaries like bunzip2 and bcat is negligible

I'm not saying that inodes/hardlinks are bad or useless, but can it justify the cost of the extra indirection (caching helps surely a lot, but it's no silver bullet)?

Answer 1

Hard links are besides the point. They are not the reason to have inodes. They're a byproduct: basically, any reasonable unix-like filesystem design (and even NTFS is close enough on this point) has hard links for free.

The inode is where all the metadata of a file is stored: its modification time, its permissions, and so on. It is also where the location of the file data on the disk is stored. This data has to be stored somewhere.

Storing the inode data inside the directory carries its own overhead. It makes the directory larger, so that obtaining a directory listing is slower. You save a seek for each file access, but each directory traversal (of which several are needed to access a file, one per directory on the file path) costs a little more. Most importantly, it makes it a lot more difficult to move a file from one directory to another: instead of moving only a pointer to the inode, you need to move all the metadata around.

Unix systems always allow you to rename or delete a file, even if a process has it open. (On some unix variants, make this almost always.) This is a very important property in practice: it means that an application cannot “hijack” a file. Renaming or removing the file doesn't affect the application, it can continue reading and writing to the file. If the file is deleted, the data remains around until no process has the file open anymore. This is facilitated by associating the process with the inode. The process cannot be associate with the file name since that may change or even disappear at any time.

See also What is a Superblock, Inode, Dentry and a File?

Answer 2

You might have missed out on a few other factors. The separation of inode from file name in a directory enables hard links, but I doubt that hard links constitute the only, or even the original, motivation for that separation.

I have a copy of "The Bell System Technical Journal", July-August, 1978. This is one of their special issues, and it's titled "The Unix Time Sharing System". That's the place where Thompson, Ritchie and company published their description of version 6 and 7 Unix, and what you could do with it.

I see descriptions of inodes and the file system, but no motivations for the design. Ritchie and Thompson note that a create (their spelling in the BSTJ) system call makes the inode and sets the values, while open system calls fill in OS table(s) that can hold inode data on further file accesses.

One of the key paragraphs talks about the chunk of disk holding inodes, which they called the i-list:

The notion of the i-list is an unusual feature of UNIX. In practice, this method of organizing the file system has proved quite reliable and easy to deal with. ... It also permits a quite simple and rapid algorithm for checking the consistency of a file system, ... This algorithm is independent of the directory hierarchy, because it need only scan the linearly organized i-list.

        — Source

The original designers found that keeping inodes separate from data made things more reliable.

I believe we can point to years of experience making that true. MS-DOS and other filesystems where the directory hierarchy is all mixed up with the allocation (FAT) are pretty fragile. If a sector in the FAT goes bad, things are really difficult to recover. But if a sector in a Unix directory goes bad, then the inode, somewhere else on the disk, is still around, with a link-count that indicates it belongs to some directory, and thus can be recovered.

It looks like maybe the obvious overhead of looking in a directory for an inode number, then looking in the inode for permissions or data, is compensated for by either making the OS handling of files simpler, or by greater reliability.

Answer 3

1 practical inode example:

you have a file with a tricky name (example ~*) and you need to delete it.

ls
~*

rm -rf ~* damages your $HOME, so you have to delete it in another way.

Read here how to delete files by inode.

Delete file by inode:

find . -type f -inum 1234 - exec rm -rf {} /;

ok, i know you can escape the special characters and simply delete it with rm, or use the -- trick, but still.

Answer 4

Hard links aren't used just for files; . is an actual link in the filesystem, thus every directory has at least two filesystem links--- its full pathname and the . link. Add in the .. links and a directory can have many hard links.