#Filesystem

ZFS

In the previous article , we explored Btrfs—a copy-on-write filesystem built around a single kind of B-tree, where every file, extent, checksum and chunk mapping lives as a tagged item in some tree, and snapshots fall out of the reference-counted extent design. Btrfs took a lot of inspiration from an older system that pioneered most of these ideas: ZFS.

ZFS started life at Sun Microsystems in the mid-2000s and now lives on as OpenZFS, ported to Linux, FreeBSD, illumos, and macOS. From the outside it solves the same problems as Btrfs—pooled storage, copy-on-write, snapshots, checksums, integrated RAID—but the shape underneath is genuinely different. Where Btrfs leaned on one universal B-tree node format and a single key shape, ZFS leans on something else entirely: a 128-byte block pointer that fully describes the block it points to, and a strict three-layer architecture stacked on top of it.

Btrfs

In the previous article , we explored XFS—a filesystem built for extreme scale that divides the disk into independent Allocation Groups, each with its own B+ trees for free space, inodes, and extent tracking. XFS, like every filesystem we’ve covered in this series, shares one fundamental characteristic with ext4, NTFS, and FAT32: it modifies data in place. When you update a block, the new data overwrites the old data at the same disk location.

XFS

In the previous article , we explored NTFS—a filesystem where everything is a file, from your documents to the Master File Table itself. NTFS centralized all metadata into the MFT, using attribute-based records and a single journal to keep Windows volumes consistent and feature-rich.

Now let me introduce you to XFS, the filesystem designed for extreme scale. Originally built by Silicon Graphics in 1993 for their high-end IRIX workstations, XFS was engineered to handle filesystems measured in terabytes when most systems still counted in megabytes. Its core idea is to divide the disk into independent regions called Allocation Groups—each with its own free space tracking, its own inode management, and its own locks. This simple design choice is what allows XFS to scale linearly with the number of CPU cores and support filesystems up to 8 exabytes.

NTFS

In the previous article , we explored ext4—a filesystem that divides the disk into block groups and separates metadata from data, with inodes in one place and file content in another.

NTFS takes a radically different approach. In NTFS, everything is a file—the allocation bitmap, the journal, even the Master File Table that tracks all the other files. This single idea shapes the entire design: the same mechanisms that store your documents also store the filesystem’s own bookkeeping.

Ext4

In the previous article , we explored FAT32—a filesystem that conquered the world through simplicity. Its linked-list approach gets the job done, but it comes with real limitations: no crash protection, linear directory searches that slow down as directories grow, and a hard 4GB ceiling on file sizes.

Ext4 takes a fundamentally different approach. Where FAT32 uses a single table as both its allocation tracker and file map, ext4 divides the disk into block groups, each with its own dedicated structures for tracking free space and storing file metadata. Where FAT32 walks a linked list to find your data, ext4 uses extents—a compact B-tree where each entry describes a contiguous run of blocks. And where FAT32 has no crash protection at all, ext4 uses journaling to ensure your filesystem stays consistent after unexpected shutdowns.

FAT32

In the introduction to this series , we covered the foundational concepts every filesystem needs: sectors, blocks, partitions, and the four essential services—naming, allocation, metadata, and crash recovery. Now let’s see how a real filesystem puts these into practice.

FAT32 is everywhere. USB drives, SD cards, digital cameras—if you’ve ever moved files between a Windows PC, a Mac, a Linux machine, or your car’s stereo, FAT32 made it work. What makes it fascinating isn’t complexity—it’s the opposite. FAT32 is beautifully simple, and that simplicity is exactly why it conquered the world.

Introduction

Every time you save a document, download a photo, or install an application, you’re trusting a filesystem to keep your data safe. Think about it—filesystems are this invisible layer between your applications and raw storage hardware. They turn a sea of numbered blocks into the familiar world of files and folders that we all take for granted.

But what exactly does a filesystem do? And what makes it so tricky to get right? In this series, we’re going to explore filesystems like FAT32, ext4, Btrfs, and others. But before we get there, I want to build a solid foundation with you. We’ll start at the very bottom—how storage hardware actually works—and work our way up to the abstractions that filesystems provide.