Linux - Inode vs. File Descriptor
If you are diving into Linux systems programming or DevOps, you will constantly run into two terms: Inode and File Descriptor (FD).
At first glance, they both seem to represent "a file." But in reality, they exist at completely different levels of the operating system. One is about storage, and the other is about sessions.
The Inode
Level: Filesystem (Disk)
An Inode (index node) is a data structure on your hard drive that describes a file or directory. Every file on your disk has exactly one Inode.
- What it stores: File size, owner, permissions, timestamps, and—most importantly—the addresses of the data blocks on the disk where the actual content lives.
- What it DOES NOT store: The filename. In Linux, filenames are just pointers to Inodes stored in a directory.
- Persistence: It is permanent. It stays on the disk even if the computer is turned off. It only disappears if the file is deleted (unlinked).
The File Descriptor
Level: Process (Kernel/RAM)
A File Descriptor is a temporary handle used by a running program to interact with a file. It is a non-negative integer (like 0, 1, 2, 3...).
- What it stores: It represents an active session. It tracks things like your current "offset" (where you are currently reading in the file) and the mode (read-only, write-only, etc.).
- Scope: It is per-process. If two different programs open the same file, they each get their own unique FD number.
- Persistence: It is ephemeral. If the program closes or the system reboots, the FD vanishes. It exists only in the system's RAM.
The Library Analogy 📚
Imagine a massive city library:
- The Inode is the Book on the shelf. It has a unique ISBN, a specific number of pages, and a fixed physical location in the building. Even if nobody is reading it, the book exists.
- The File Descriptor is a Borrower’s Slip. When you go to the desk and "open" a book, the librarian gives you a slip. This slip tracks which page you are currently on.
- If five people borrow the same book, there is still only one book (one Inode), but there are five slips (five FDs), each tracking a different person's progress.
- When you leave the library (the process ends), your slip is shredded (the FD is closed), but the book remains on the shelf.
Key Differences at a Glance
| Feature | Inode | File Descriptor (FD) |
|---|---|---|
| Location | Stored on the Disk (Filesystem) | Stored in RAM (Kernel) |
| Lifetime | Persistent (Survives reboots) | Ephemeral (Dies with the process) |
| Scope | System-wide / Filesystem-wide | Private to a specific Process |
| Content | Metadata (Size, Owner, Blocks) | Session data (Offset, Read/Write mode) |
| Identification | Inode Number (e.g., 128456) | Integer (e.g., 3) |
How They Work Together
When you run a command like cat notes.txt, the following chain reaction happens:
- The Lookup: The OS looks at the directory to find which Inode number is linked to the name "notes.txt".
- The Open: The kernel checks if you have permission (stored in the Inode) to read the file.
- The Assignment: The kernel creates an entry in your process's FD Table and points it toward that Inode. It returns an integer (the FD) to your program.
- The Action: When your program says "Read FD 3," the kernel knows exactly which Inode to look at and where you left off reading last time.
Why does this matter?
Understanding this distinction explains some "weird" Linux behavior. For example: How can you delete a file that is currently being used by a program?
When you rm a file, you delete the filename and tell the system to eventually delete the Inode. However, if a program still has an open File Descriptor pointing to that Inode, the Inode remains "alive" in the background. Only when the program closes the FD (or crashes) does the Inode finally get erased from the disk.