Linux File Systems & Inodes

Learning outcomes

• Understand inode allocations and directory metadata structures
• Optimize disk I/O with page cache flush settings

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.

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.

# Check inode usage on file system
df -i

# Inspect specific file inode number and metadata
ls -i /etc/passwd
stat /etc/passwd

# Create Hard Link vs Soft Link
ln /var/log/app.log /var/log/app_hard.log
ln -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

1. "No Space Left on Device" when Disk Space is Available: Creating millions of microscopic files exhausts all allocated Inodes (df -i reads 100%), even when gigabytes of disk space remain free (df -h reads 20%).
2. 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.

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.

Primary sources

• Linux Kernel Kernel.org Official Architecture & Systems Documentation — Linux Kernel Organization, verified 2026-07-23