Learn Linux Filesystem - Core Concepts & Anatomy

#Introduction

After understanding the history, it's time to dissect the internal anatomy of a filesystem. When you create a file on Linux, many things happen behind the scenes: the superblock is read, an inode is allocated, data blocks are reserved, and the journal or COW mechanism records the transaction. Understanding these layers makes commands like tune2fs or zfs set feel logical.

Episode 2 covers the four pillars of filesystem concepts: inode, superblock, block allocation, and data integrity. Plus one crucial abstraction layer that makes all filesystems work uniformly on Linux: VFS (the Virtual Filesystem Switch).

The concepts in this episode are universal — they apply to ext4, XFS, btrfs, and ZFS alike. The difference is only in how each one implements them. Once you master these pillars, learning a new filesystem just means reading its documentation.

#Inode and Superblock

#Inode: A File's Identity

An inode is the data structure that stores a file's metadata: size, owner, permissions, timestamps, hard link count, and the location of data blocks. The file name itself isn't stored in the inode — names are stored in directories, which simply map names to inode numbers.

Try looking at the inode of any file:

ls -li /etc/hostname

The first column of the output is the inode number. Every filesystem has an inode table with limited capacity — ext4 creates roughly one inode per 16KB by default. If a filesystem is full of inodes but still has free space, this is what's happening.

#Superblock: A Filesystem's Identity Card

The superblock is the block that stores metadata for the entire filesystem: type, block size, block and inode counts, UUID, and feature flags. Because it's crucial, the superblock is duplicated in several locations for redundancy.

Inspect the contents of an ext4 superblock:

sudo dumpe2fs -h /dev/sda1

The dumpe2fs -h output shows the block size, inode count, UUID, and enabled features. If the primary superblock is damaged, e2fsck -b 32768 can use the backup superblock — we'll cover this in episode 11.

#Block Allocation and On-Disk Structure

#Blocks and Fragmentation

File data is stored in blocks — the smallest allocation unit, usually 4KB. Two main allocation strategies exist:

• Block bitmap (ext2/early ext4): a simple bitmap marks used blocks; prone to fragmentation because blocks are scattered.
• Extent (ext4, XFS): stores ranges of sequential blocks as a single entry; one large file can be covered by just a few extents.

Check the extents of a file with:

sudo filefrag -v /etc/hostname

filefrag -v shows the file's extent list. A fragmented file has many extent lines, while a contiguous file has one or two. Fragmentation lowers read performance because the disk head has to move.

#Flexible Block Groups

ext4 introduced flexible block groups: several block groups are grouped together so that metadata (bitmaps and inode tables) is clustered in one area. This reduces disk head movement when allocating inodes and blocks together — a major improvement over ext2/ext3.

#Journaling vs Copy-on-Write

#Journaling: A Record Before Writing

Journaling writes a transaction description to the journal before the data is actually modified. ext4 supports several modes:

• data=writeback: only metadata is journaled; fastest, least safe.
• data=ordered: metadata is journaled after data is written; ext4 default, balanced.
• data=journal: both data and metadata are journaled; safest, slowest.

Check the journaling mode of your filesystem:

mount | grep " / "

Note the rw,relatime,errors=remount-ro,data=ordered part — that's where the journaling mode shows up.

#Copy-on-Write: Atomic and Consistent

Copy-on-Write (COW) is used by btrfs and ZFS. Data is never overwritten; new blocks are filled with new data, and the pointer is changed to point to the new blocks. As long as a snapshot exists, the old blocks are kept — this is why COW snapshots are nearly instant and cheap. The downside: higher fragmentation, and small workloads can be slower without tuning.

COW also eliminates the need for a journal, because pointer changes are atomic — the system never sees a half-finished state.

#Checksum and Self-Healing

#Detecting Silent Corruption

Traditional filesystems can't tell if a bit inside a block has changed due to a bad sector or bit rot. Checksums solve this: every data block stores its cryptographic digest. When a block is read, the checksum is verified; if it matches, the data is considered intact.

Check this mechanism on ZFS:

sudo zpool status

If any block's checksum fails, the CKSUM column shows a non-zero number.

#Self-Healing and Scrub

Self-healing is the advantage of btrfs and ZFS: when a checksum fails but the filesystem has another copy (mirror or parity), the data is automatically recovered from the healthy copy. Scrub is a routine full-data read to detect and recover corruption before you actually need that data.

Note the difference: ext4 and XFS use metadata checksums (detecting structure corruption), while btrfs and ZFS verify all data and can repair it themselves.

#VFS: One Interface for All Filesystems

#What Is VFS

The Virtual Filesystem Switch is an abstraction layer in the Linux kernel that provides one set of standard syscalls — open, read, write, stat — regardless of the underlying filesystem. Thanks to VFS, application programs don't need to know whether a file is on ext4, XFS, NFS, or tmpfs.

The directory tree structure is uniform: every filesystem is mounted under the root /, forming a single global namespace. This is what lets Linux combine many different filesystems into one directory structure.

Simulate what VFS does every time a program reads a file:

proses → syscall open() → VFS → filesystem-specific driver → block device

Every file on Linux follows this flow. Understanding VFS explains why one mount point can be an ext4 filesystem while another is ZFS, without the application ever noticing.

#Conclusion

Filesystem anatomy turns out to be made of interconnected components: inodes store metadata, the superblock is the identity card, block allocation determines performance, and integrity mechanisms determine data safety. VFS unifies them all behind a single uniform interface for applications.

Key takeaways:

• Inodes store file metadata; a file name is just a directory's mapping to an inode.
• The superblock is a filesystem's identity card, complete with features and UUID.
• Extents (ext4/XFS) beat block bitmaps when it comes to fragmentation.
• Journaling records transactions; COW writes new data then changes the pointer.
• Checksum + self-healing distinguishes btrfs/ZFS from ext4/XFS.
• VFS makes all filesystems look uniform to applications.

In the next episode, episode 3, we dive into your first hands-on practice: ext4 — concepts, tools, and daily operations. You'll create an ext4 filesystem from scratch, inspect it with dumpe2fs, resize it, and run e2fsck. Get your loopback disk from episode 0 ready!