Linux File Systems: Inodes, Superblocks & VFS

Introduction: Everything is a File

In Linux, the mantra "Everything is a file" is more than just a philosophy—it's an architectural reality. But what exactly is a file? To you, it's a document named resume.pdf. To the operating system, it's just a number.

This post explores the fascinating machinery beneath the ls command: how Linux organizes data on disk, what an "inode" actually is, and how the Virtual File System (VFS) allows you to access a USB drive, a hard disk, and a network share using the exact same commands.

The Inode: What a file really is

The most important concept to grasp is the Index Node, or inode.

                    Crucial Concept: The filename is NOT part of the file. The filename is just a label
                    stored in a directory that points to the file's inode. The inode contains the actual metadata.
                

What's Inside an Inode?

An inode is a data structure (typically 128 or 256 bytes) that stores everything about a file except its name and its actual data content.

Inode #42069

Type Regular File

Permissions rw-r--r--

Owner ID 1000 (omar)

Size 2048 bytes

Timestamps mtime, atime

Link Count 1

Block Pointers [102, 103, ...]

Block 102
(Data)

Block 103
(Data)

Block 104
(Empty)

Block 105
(Empty)

The inode points to the specific blocks on the disk where the data lives.

You can see a file's inode number using the -i flag:

                    
$ ls -li resume.pdf
42069 -rw-r--r-- 1 omar users 2048 Jul 12 10:00 resume.pdf

The Superblock: The Filesystem's Passport

If the inode describes a file, the Superblock describes the entire filesystem. It lives at the beginning of the partition and contains critical metadata:

Total size of the filesystem
Block size (e.g., 4KB)
Total number of inodes
Free block count
Filesystem status (clean/dirty)

Critical Failure: If the superblock is corrupted, the filesystem cannot be mounted. This is why Linux maintains multiple backup copies of the superblock scattered across the disk.

Directories: Just Files with Lists

If the inode doesn't store the filename, where is it?

It's in the directory. A directory in Linux is just a special file containing a list of (filename, inode_number) pairs. That's it.

Contents of /home/omar/docs/

Filename	Inode Number	Type
.	501	Current Dir
..	400	Parent Dir
resume.pdf	42069	File
photo.jpg	42070	File
notes.txt	42071	File

When you run mv resume.pdf cv.pdf, you aren't moving the file data. You are simply updating the entry in this directory list to point inode 42069 to a new name cv.pdf. This is why renaming a 100GB file is instantaneous.

Hard Links vs. Soft Links

Understanding inodes makes the difference between hard and soft links obvious.

Hard Link

Two names, ONE inode.

file_a.txt

file_b.txt

Inode

DATA BLOCKS

If you delete file_a.txt, file_b.txt still works because the inode still exists (link count > 0).

Soft (Symbolic) Link

A file pointing to a path.

shortcut.txt

Content: "/path/to/original.txt"

↓

original.txt

Inode

If you delete original.txt, the shortcut breaks because it points to a path that no longer exists.

The Virtual File System (VFS)

Linux supports dozens of file systems: ext4, xfs, btrfs, ntfs, fat32. How can programs like cp or vim work with all of them without knowing the details?

Enter the Virtual File System (VFS). It's an abstraction layer that provides a common interface for all file systems.

User Applications (ls, vim, chrome)

Calls open(), read(), write()

↓

Virtual File System (VFS)

"The Universal Translator"

↓

ext4 Driver

NTFS Driver

NFS Driver

↓

Physical Storage / Network

When you call read(), the VFS receives the request. It looks at the file's mount point, determines it's an ext4 file system, and translates the generic read() into the specific ext4_read() function.

This is why you can mount a Windows NTFS drive or a network NFS share and treat them exactly like native Linux folders.

The Filesystem View: How Others Do It

Not all filesystems use inodes. Here's how Linux compares to others:

FAT32 (USB Drives)

Uses a File Allocation Table. Simple, universal, but fragile. No permissions, no owners, max file size 4GB.

NTFS (Windows)

Uses a Master File Table (MFT). It's like a relational database. Supports permissions and journaling.

Btrfs & ZFS (Modern)

Copy-on-Write (CoW). They never overwrite data; they write new data and move the pointer. Allows instant snapshots and rollback.

Journaling: Why Unplugging Doesn't Kill Your Data

Modern filesystems like ext4 are journaling filesystems. They keep a log (journal) of changes they intend to make before actually making them.

The Crash Scenario:

You save a file.
System writes metadata to the journal ("I am about to allocate block 500").
POWER FAILURE! The system crashes before writing the actual data.
Reboot: The OS checks the journal. It sees the unfinished entry and simply "replays" or discards it to return to a consistent state.

Without a journal (like in ext2), the OS would have to scan the entire disk (fsck) to find inconsistencies, which could take hours.

Practical Detective Work

You can explore these structures yourself using standard commands:

                    
# View filesystem usage and type
$ df -Th

# View inode usage (if you run out of inodes, disk is "full" even if space remains!)
$ df -i

# View detailed file stats (inode, blocks, links)
$ stat filename.txt

# View superblock information (requires root)
$ sudo dumpe2fs /dev/sda1 | grep "Superblock"

Conclusion

The Linux file system is a masterpiece of abstraction.

Inodes decouple metadata from filenames.
Directories are just mapping tables.
VFS decouples applications from physical storage formats.

Understanding these layers gives you superpowers when debugging storage issues, recovering lost files, or optimizing system performance.