Mental model
In Linux, file content is stored in Data Blocks, while file metadata (permissions, ownership, size, pointers to data blocks) is stored in an Inode (Index Node). File names do NOT live in inodes; file names exist in Directory Entries (dentries) mapping names to inode numbers.
Directory Entry (Filename -> Inode #)
Read Inode Metadata (Owner, Mode, Block Pointers)
Kernel Page Cache Lookup
Disk Block Allocation (ext4 Extents)
sync / fsync Flush to Storage
Theory
- Inode Structure: Contains metadata for a single file. An inode does not store the filename.
- Hard Link: A new directory entry pointing to an existing inode number. Increment's the inode link count. Deleting one file name does not delete data until link count reaches 0.
- Symbolic (Soft) Link: A special file containing a text string path pointing to another filename.
- ext4 Extents: Replaced block-by-block pointers with contiguous block range allocations (extents), improving large file read/write performance.
bash(11 lines)
1# Check inode usage on file system
2df -i
3
4# Inspect specific file inode number and metadata
5ls -i /etc/passwd
6stat /etc/passwd
7
8# Create Hard Link vs Soft Link
9ln /var/log/app.log /var/log/app_hard.log
10ln -s /var/log/app.log /var/log/app_soft.log
Alternatives and trade-offs
- ext4: Robust, battle-tested journaling file system; fixed inode count allocated at format time.
- XFS: High performance, dynamic inode allocation, parallel allocation groups; ideal for large database storage volumes.
Failure modes and misconceptions
- "No Space Left on Device" when Disk Space is Available: Creating millions of microscopic files exhausts all allocated Inodes (
df -ireads 100%), even when gigabytes of disk space remain free (df -hreads 20%). - Deleting Unlinked Open Files: Deleting a file (
rm app.log) while a background process keeps the file handle open removes the dentry, but the kernel retains the inode and data blocks on disk until the process closes the file descriptor.
Reflect before revealing the guide
Decision scenario
Monitor both disk space usage (df -h) and inode consumption (df -i) in production to prevent storage failures caused by inode exhaustion.
Learning outcomes
- Explain how dentries, inodes, and disk data blocks interact.
- Distinguish hard links (shared inode pointers) from soft symbolic links.
- Diagnose storage failures caused by inode exhaustion.
Trade-offs
ext4 journaling ensures filesystem consistency after unexpected crashes, but fixed inode formatting requires monitoring inode exhaustion on dense file workloads.