ZFS — A Different Philosophy Entirely

Btrfs (fs1-3) shares two real ideas with what's coming next — copy-on-write and built-in checksums. ZFS takes both further, and adds one more: it doesn't just sit on top of a partition, it manages the disks, the redundancy, and the filesystems all as one integrated system. That's the genuinely different philosophy this chapter is about.

The Integrated Pool/Dataset Model

The traditional stack — and Btrfs, mostly — still separates layers: a partition or RAID array, then (optionally) LVM, then a filesystem on top. Each layer is configured independently, with its own tools and its own failure modes.

ZFS collapses all of that into one system. A zpool is built directly from raw disks or partitions, with redundancy (mirroring, RAID-Z) configured at pool-creation time — no separate mdadm or LVM layer needed underneath at all. Datasets (ZFS's own term for filesystems) are then carved out of that pool on demand, each one a lightweight, independently-configurable filesystem sharing the pool's underlying storage and free space.

One command creates a mirrored, redundant storage pool from two raw disks. Another carves a dataset out of it. No partitioning step, no separate RAID tool, no separate volume manager — ZFS is all three layers.

Real Strengths

• Checksums — data and metadata, verified on every read, same principle as Btrfs (fs1-3) — ZFS pioneered this approach.
• Snapshots and clones — the same COW-based, near-instant, near-free mechanism as Btrfs: zfs snapshot tank/data@backup1.
• send/receive — a genuinely unique, powerful capability: replicate exactly the changed blocks between a snapshot and its predecessor to another pool or host, efficiently and incrementally.
• RAID-Z — ZFS's own answer to RAID5/6, designed specifically to avoid the "RAID write hole" (a power-loss-during-write scenario that can silently corrupt a traditional RAID array's parity) by tying redundancy directly into the same transactional, copy-on-write model as everything else in ZFS.

A Worked Example — send/receive Replication

The -i incremental form sends only the blocks that changed between the two snapshots, not the entire dataset again — a genuinely efficient replication mechanism for keeping a remote backup pool current, night after night, without re-transferring unchanged data.

An Honest Note on Linux Licensing & Kernel Integration

ZFS originated at Sun Microsystems and is licensed under the CDDL — a license the Linux kernel's own maintainers and the FSF consider legally incompatible with the GPL for the purpose of shipping ZFS built directly into the mainline Linux kernel. This is a real, ongoing legal position, not a technical limitation of ZFS itself.

The practical consequence: ZFS on Linux (distributed as OpenZFS) ships as an out-of-tree kernel module built via DKMS, not bundled with the kernel the way Btrfs has been since 2009. Some distributions make this easy (Ubuntu ships it as a straightforward installable option); others require more manual setup. On FreeBSD, by contrast, ZFS ships natively with no such licensing tension at all — this friction is genuinely Linux-specific, not a limitation of ZFS itself.

Hands-On Exercises