What is a Superblock, Inode, Dentry and a File?
Documentation of Unix-file-systems contains often the term 'inode'. What is that and what does that? Why have DOS/Windows-filesystems no inodes (or do they)?
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.Sign up to join this community
"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.