Different Filesystems in Linux

A freshly partitioned disk isn’t usable yet — a partition is just a defined region of raw space, with no structure telling anything where one file ends and another begins. A filesystem is what imposes that structure, and choosing the wrong one for a given situation is a genuinely consequential decision, not a cosmetic preference. This chapter covers what a filesystem actually does under the hood, and why ext4, xfs, and btrfs — the three you’re most likely to encounter — aren’t just interchangeable options with different names.

What A Filesystem Actually Does

A filesystem is responsible for three core jobs: tracking which parts of the partition are in use and which are free, storing metadata about every file (permissions, owner, timestamps — everything covered back in the Permissions section), and mapping human-readable paths like /home/you/notes.txt to the actual raw data sitting somewhere on disk.

That metadata is stored in a structure called an inode — one per file, containing everything about that file except its actual name. The filename itself lives separately, in a directory entry that simply points at an inode. This split is why, on the same filesystem, a single file’s contents can technically be reachable through more than one filename — the names are just pointers to the same underlying inode. You won’t create that kind of link hands-on in this course, but understanding that a filename and a file’s actual data are two separate things, connected through an inode, explains a fair amount of filesystem behavior that would otherwise seem strange.

Why Journaling Matters

Writing data to disk isn’t instantaneous or atomic — a power failure or crash mid-write can leave a filesystem in an inconsistent state, with metadata that doesn’t match what’s actually on disk. Older filesystems handled this by running a lengthy, full-disk consistency check after any unclean shutdown, which could take a long time on a large disk.

A journal solves this more efficiently: before making a change, the filesystem first writes a short record of what it’s about to do into a dedicated journal area. If the system crashes mid-operation, it can replay or discard that journal entry on the next boot, quickly restoring consistency without scanning the entire disk. All three filesystems covered in this chapter are journaling filesystems (though btrfs achieves crash consistency through a different mechanism, covered below) — this is table stakes for anything you’d run in production today, not a differentiating feature between them.

ext4: The Reliable Default

ext4 is the direct descendant of a long lineage (ext2, ext3, ext4) and is the default filesystem on most Debian and Ubuntu installations. It’s mature, extremely well understood, predictable in behavior, and has no unusual quirks to learn — which is exactly its appeal. Unless you have a specific reason to reach for something else, ext4 is a genuinely safe default for general-purpose use.

xfs: Built For Large Files And High Throughput

xfs was designed with an emphasis on handling very large files and high parallel I/O throughput efficiently — it tends to perform particularly well on workloads involving large files being written and read concurrently, like database storage or media files. It’s the default filesystem on RHEL and several other enterprise-focused distributions.

One practical limitation worth knowing: xfs partitions can be grown (expanded) easily, but cannot be shrunk at all once created — if there’s a real chance you’ll need to reduce a volume’s size later, that’s a meaningful constraint to plan around in advance.

btrfs: Modern Features, More Complexity

btrfs (“B-tree filesystem”) takes a different underlying approach — it’s a copy-on-write filesystem, meaning changes are written to new locations on disk rather than overwriting data in place, which is what enables some of its more advanced features directly at the filesystem level:

• Snapshots — near-instant, space-efficient point-in-time copies of the filesystem’s state, useful for quick rollback before a risky change
• Built-in checksumming — btrfs can detect (and, with redundancy configured, correct) silent data corruption that ext4 and xfs wouldn’t notice on their own
• Native multi-device support — btrfs can span, mirror, or stripe across multiple disks without needing a separate layer like LVM or RAID for some of those use cases

The tradeoff is complexity — btrfs has more moving parts, more configuration decisions, and a smaller (though growing) track record compared to ext4’s decades of predictable, uneventful use.

Comparing All Three

Choosing One In Practice

For most general-purpose systems — and everything in the rest of this course — ext4 is the right, boring, reliable choice, which is exactly why it’s what we’ll use in the hands-on examples ahead. Reach for xfs specifically when you know you’re dealing with large files and heavy parallel throughput, and you’re confident you won’t need to shrink the volume later. Reach for btrfs when snapshotting or built-in corruption detection is a real requirement worth the added complexity, not just a feature that sounds appealing in the abstract.

What’s Next

You now understand what a filesystem actually is and have a real basis for choosing between the three you’re most likely to encounter. The next chapter makes it concrete: actually creating a filesystem on a partition with mkfs.