Combining Layers — Traditional Stack vs. Integrated Filesystems

Every piece is now on the table: ext4 (fs1-2), Btrfs (fs1-3), ZFS (fs1-4), LVM (fs1-5, fs1-6), RAID concepts (fs1-7) and mdadm (fs1-8). This chapter is the course's own synthesis: two genuinely different philosophies for assembling them into a real storage stack, laid out honestly, tradeoffs and all.

The Traditional Layered Stack

Raw disks → mdadm RAID → LVM (PV/VG/LV) → ext4 (or XFS) → mount. Four separate subsystems, each configured, monitored, and troubleshot independently — mdadm --detail for RAID health, lvs for LVM, tune2fs/dumpe2fs for the filesystem itself.

The real benefit is composability: any single layer can be swapped without touching the others — hardware RAID in place of mdadm, XFS in place of ext4 — the classic Unix "do one thing well" philosophy applied to storage, genuinely mature and well understood.

The real cost is that each layer has zero awareness of the others. RAID doesn't know about the filesystem's own data; the filesystem doesn't know the RAID layer even exists. And, per fs1-2, ext4 itself does no content checksumming at all — nothing in this entire four-layer stack is actually verifying that the bytes coming back out are the bytes that were written.

The Integrated Approach — Btrfs and ZFS

Btrfs's own built-in RAID profiles and ZFS's own RAID-Z (fs1-4) eliminate the separate RAID layer entirely — the filesystem is the volume manager is the redundancy layer, all one system.

This is the concrete mechanism behind the "self-healing" claim from fs1-3/fs1-4: checksumming can only repair corruption automatically if the same system that detects the bad checksum also knows exactly which redundant copy holds the good data — and that's only possible once there's no longer a layer boundary between "the data" and "the redundancy" for that information to get lost across. A traditional mdadm array has no such awareness — it faithfully mirrors or reconstructs whatever bytes it's given, healthy or corrupted, because it operates below the filesystem with no concept of "correct" content at all.

The real cost: less mix-and-match flexibility — swapping ZFS's own RAID-Z for a different vendor's RAID implementation isn't really an option the way swapping mdadm for hardware RAID is in the traditional stack — and, per fs1-4, ZFS specifically still carries real Linux kernel-integration friction.

A Concrete Illustration — Where Silent Corruption Gets Caught

Revisit fs1-3's own bit-rot scenario through the lens of layering. In the traditional stack: a bit flips on one disk's physical media. mdadm has no checksum, so it can't distinguish the bad block from a good one — it does its normal job with whatever bytes it reads. LVM, above that, has no checksum either. ext4, above that, has none either (fs1-2). The corrupted data sails all the way up to the application, undetected at every single layer along the way.

In the integrated approach, the filesystem stores the checksum right alongside the data it protects and verifies it on every read — regardless of which physical disk or redundancy scheme sits underneath, because there's no longer a boundary for the corruption to slip past unnoticed.

Which Approach the Site's Own Courses Actually Use

Worth being honest about: ws1's own web server course, and most of this site's Linux material generally, assumes a fairly traditional setup — plain partitions, sometimes LVM — rather than Btrfs or ZFS. That's not an oversight; it reflects that ext4 is still the overwhelmingly common real-world default across most Linux distributions' own installers. This directly echoes fs1-2's own honest framing: "traditional" doesn't mean "obsolete," it means "still the default almost everywhere."

Hands-On Exercises