1 Answer
1

"inode" is the informal term that refers to whatever on-disk chunk of data a Unix-file-system uses to hold the information pertaining to a single file. An "inode" traditionally holds the block numbers of disk blocks holding the file's actual contents. A directory entry traditionally held file name, file type, etc. The two chunks of data were separated.

That said, a lot of Unixy-things fall out of it. Traditionally, a file name wasn't part of the inode. The file name came from a "directory", a file (which had it's own inode and contents) that matched up file name to inode number. A C-preprocessor macro allowed code to go from inode-number to disk block with very little calculation.

So, many names could refer to the same inode. Hard links come out of this. So does the ability to have "." always refer to the current directory without trickery. A directory always contains "." and ".." filenames, which correspond to the inode numbers of the directory itself, and the directory in which the directory resides. "." and ".." filenames have entrys in each and every directory. They're not special cases in the filesystem code that don't really have data anywhere.

The hierarchy of Unix files come out of the inodes. A disk is essentially a linear array of "blocks" of a certain size, 512 bytes, 1 kilobytes, 4 kilobytes, whatever. Inode 0 was always at a designated disk block, allowing the Unix kernel to find the root of a filesystem by just knowing "inode 0", and it could associate "/" with inode 9. Inode 0 was also a directory file. "usr", "bin", "tmp", "dev" etc had entries in inode 0. So the inodes allow mapping a linear list of blocks of data from a disk into a hierarchical structure.

Inodes lived on-disk. In the original unix filesystem, the first third or quarter of a disk was inodes. The rest was data blocks, allocated to files as needed, and whose disk block numbers ended up in inodes. Various fileystems over the years (BSD FFS, for example) tried to take into account the actual physical geometry of the disk by putting zones of inodes at different places on the disk.

The Winodws NT "NTFS" filesystem has something immediately analogous to an inode: entries in the master file table. NTFS seems to have inherited that from its ancestor, DEC VMS Files-11. Files-11 "file headers" appear almost identical to entries in $MFT.

I'm not at all expert with other Windows/DOS filesystems (FAT, FAT32, etc etc), but the records in the File Allocation Table seem like analogs of a combined directory entry and inode to me. I imagine that combining naming and hierarcy along with disk block data is what makes FAT filesystems so fragile. You can't have a program comb through separate inode on-disk data and put the files it finds into "lost+found" - once the File Allocation Table gets corrupted, blocks membership in files data is lost, as well as files membership in directory.

+1 for this answer. Just out of curiosity: Is it possible to access the innode of a file. In otherwords can I alter an innode of a file without ever accessing the file?
–
DBSMar 13 at 22:39

@DBS - If you're clever and careful, you could probably open the "raw device", /dev/sda1 or whatever, find the on-disk data, and modify it without touching the file's actual data. Other than that, the chmod command changes inode without accessing file data.
–
Bruce EdigerMar 13 at 22:46

I am afraid I am probably neither! I was reading Kernighan Pike (Unix Programming) and saw about innodes. I was wondering since everything in Unix is a file where would be the innode of innodes... (sort of like Russell's paradox).
–
DBSMar 13 at 22:50

@DBS - interesting thought, dragging Russel's Paradox into Unix filesystems. Alas, "everything is a file" only went so far, rather like sets in NBG set theory giving way to classes at some point, and then, only in user land. In the kernel, not everything is a file.
–
Bruce EdigerMar 14 at 15:18