You click on a file. Your operating system knows exactly where it lives, what you can do with it, and whose responsibility it is. But have you ever wondered what makes this instant recognition possible? The answer is the inode. It is not the file itself. Not the filename. Something far more fundamental.
Think about a library. You see a book with a title on the spine. The title is not the book. It is merely a label. The actual book sits on the shelf containing pages. The librarian has an index card for that book.
The index card stores real information: location, size, who checked it out, and when last modified. This card remains the same even if the book’s title changes or it gets moved. This is exactly what an inode does.
Understanding What an Inode Actually Is
An inode is a data structure in Unix and Linux filesystems that stores metadata about files and directories. It contains everything about a file except two things: the filename itself and the actual file content. This separation is deliberately intentional.
Every inode has a unique number. When you type ls -i, that number is the inode number. It is the identity card of that file. Inside an inode live permissions, ownership, timestamps for creation, modification, and last access. File size. The number of hard links pointing to it.
Most importantly, pointers that guide the operating system to where the actual file data lives on the disk.
The Real Separation: Name Versus Identity
When you create resume.pdf, the name and the inode are separate entities. The name gets stored in its parent directory's inode. The directory maintains a simple mapping: name points to inode number. The inode itself holds everything else.
This design creates a beautiful consequence. Multiple names can point to the same inode. These are called hard links. Imagine three shortcuts to the same book, each labelled differently. Change anything in that book, and all three shortcuts see the change immediately because they all point to the same underlying data.
Your operating system does not care which name you use. Use resume.pdf or hardlink1 or a third name in a different directory. All names lead to the same inode, permissions, owner, and data. The name is merely a way to find the inode. The inode is the truth of the file.
This means something profound. If a friend has a hard link to your file, they cannot read or modify it without your permission. The permissions are stored in the inode, not the name. They can erase the name, but they cannot touch the data. Only you control that because you own the inode.
How Inodes Locate Your Data
When you open a file, your operating system performs a journey. It reads the directory containing the filename. It finds the inode number associated with that name. It loads the inode. Now it knows where to find the data because the inode contains pointers to data blocks on disk.
For small files, these pointers are direct. The inode might contain 12 direct pointers, each pointing to a data block containing file content. The operating system needs one disk read to access the inode, then direct reads to get the data.
For larger files, the filesystem employs indirection. The inode contains a pointer not to a data block, but to an indirect block. That block contains more pointers pointing to actual data blocks. For enormous files, it uses double or triple indirection, creating a tree-like structure that addresses massive amounts of data.
Hard Links and Soft Links
Hard links and soft links represent two fundamentally different approaches to creating multiple names for files.
A hard link creates another name that points to the same inode number. Both names are equal. If you delete one name, the file remains because the other name still points to the inode. The operating system only erases data when the link count reaches zero.
A soft link or symbolic link works differently. It creates a new inode. This new inode stores a path to the original file as text. When you access a soft link, the operating system reads that text path, then follows it to find the original inode. It is an indirect reference. If you delete the original file, the soft link becomes broken.
Hard links cannot cross filesystems. Soft links can cross filesystems because they simply store a text path. Hard links cost almost nothing extra. Soft links require a new inode and consume more space.
The Inode Table: A Finite Resource
When you create a filesystem, the operating system allocates a fixed number of inodes. This table exists separately from data blocks. You might have plenty of free disk space, but run out of inodes. Then you cannot create more files.
A system administrator once complained that they could not create more files despite 80 per cent disk space being free. The inode table was exhausted. Thousands of tiny files consumed all available inodes while barely touching data block space.
You can check inode usage with df -i. It shows how many inodes exist on each filesystem and how many are in use. Running out is rare, but it happens in environments generating many small files: web servers storing millions of tiny log entries, email systems with countless message files, or systems with deep directory structures.
Permissions, Ownership, and the Inode
Permissions and ownership attach to inodes, not names. You cannot change a file’s permissions by renaming it. You cannot avoid restrictions by creating a hard link in another directory. Both names access the same inode, which stores the same permissions.
The owner of a directory where a file is named does not control the file itself. You need write permission on the directory to delete the filename, but you cannot modify the file data without permission from the actual inode owner. This design prevents one user from modifying another user’s files by moving files between directories.
The Practical Impact on Your System
Understanding inodes changes how you work with files. When you delete a file with rm, you are not erasing the data. You are removing the name from the directory and decreasing the link count on the inode.
When you move a file between directories, the inode number stays the same. Moving does not copy the file. It simply updates directory entries. Moving is nearly instantaneous, even for huge files.
When you copy a file, the filesystem creates a new inode, allocates new data blocks, and copies all content. Now you have two independent files consuming double the space.
Conclusion: The Hidden Architecture
The inode represents one of Unix’s most elegant design decisions. By separating the name from identity, metadata, and data, it creates flexibility that surface-level thinking never reveals. When you access a file, you engage with invisible architecture built from inodes.
Your operating system reads inodes, follows pointers, manages metadata, and protects permissions. The filename is merely an alias for the true identity.
Understanding inodes transforms how you work with files.