ZFS: Explanation & Insights

The storage system that does everything — volume manager, RAID, filesystem, and integrity guard, fused into one.

What It Is

ZFS is what you get when you refuse to accept that storage has to be a stack of separate, mutually-suspicious layers. On a conventional Linux box, your data passes through a tower of independent pieces: a disk, maybe a partition on it, maybe a RAID array assembled by mdadm on top of that, maybe LVM on top of that, and finally a filesystem like ext4 or XFS sitting on the very top. Each layer knows only about the layer directly below it, and none of them can see the actual bytes on the physical platters. ZFS throws that tower out and replaces it with a single integrated system that owns the whole journey from raw disk to named file — and because it owns the whole journey, it can do things no layered design can.

That integration is the entire idea. ZFS is, all at once: a volume manager (it pools your disks), a software RAID (it adds redundancy across them), a filesystem (it gives you files, directories, permissions), a checksumming engine (it verifies every block it reads against a cryptographic fingerprint), a snapshot system (it freezes the state of your data in an instant), and a compression layer (it shrinks your data on the way down to disk). One tool, one mental model, one set of guarantees that hold end to end. The people who built it called it "the last word in filesystems," and the joke in the name is real: a zettabyte is a billion terabytes, a number so large you will never format a disk that needs it. They were making a point — the design ceilings are so far away they may as well not exist.

If you're new to running servers, here is the honest framing before we go deep. ZFS is the gold standard for data integrity: it is the system that catches the bit that silently flipped on disk, the corruption your hardware never told you about, and quietly fixes it from a redundant copy before it ever reaches your application. That is genuinely rare and genuinely valuable. But it asks for things in return — RAM, a little operational learning, and a willingness to live with the fact that, for licensing reasons we'll get to, it is not part of the standard Linux kernel. The rest of this page teaches you the whole system from zero, shows you the exact commands, and tells you plainly when it's worth the price and when you should reach for something simpler.

Why It Matters

Every other storage layer trusts the disk. ZFS doesn't — and that one act of distrust is why it matters.

When ext4 reads a block and the disk hands back data, ext4 believes it. It has no way not to. Modern drives have error-correcting codes and will usually report a hard read error rather than return garbage, but "usually" is doing a lot of work in that sentence. Bits rot on platters. Firmware has bugs. A cable degrades, a controller hiccups, a cosmic ray flips a bit in a buffer, a drive's own cache lies about a write it never actually committed. The data comes back wrong but plausible, the disk reports success, and every layer above it nods along. This is silent data corruption — silent precisely because nothing in a traditional stack is positioned to notice. Your database reads a corrupted row, your backup faithfully copies the corruption, and you find out months later when something doesn't add up.

ZFS notices. Every block it writes gets a checksum stored not with the block but in the metadata that points to it, one level up the tree. Every block it reads gets verified against that checksum. If they don't match, ZFS knows the data is bad — not "the disk says it's fine," but actually bad — and if you gave it any redundancy, it reaches for a good copy, returns the correct data to your application, and rewrites the bad block, all without you ever knowing it happened. That's self-healing, and once you've watched a scrub repair a handful of bad sectors on a live pool while users keep working, you understand why people who care about their data get a little evangelical about it. It is, more than any single feature, the reason ZFS exists.

The catch — and there's always a catch — is that all this costs RAM, costs a bit of complexity, and lands you on software that ships outside the kernel tree. Whether that trade is worth it depends entirely on how much you value your data, and we'll make that call concrete near the end.

The Mental Model — Pools, vdevs, and Datasets

To use ZFS you need exactly three nouns in your head. Get these and the commands write themselves.

Disks → vdevs → pool

At the bottom are your physical disks — /dev/sda, /dev/sdb, and so on. ZFS groups disks into a vdev (virtual device), and a vdev is the unit of redundancy. A vdev might be a single disk (no redundancy), a mirror of two or more disks (every disk holds the same data), or a RAID-Z group (data plus parity spread across several disks). The vdev is where the "any disk can die" promise lives or doesn't.

One level up, you combine one or more vdevs into a pool (a zpool). The pool is your unit of storage — the big bucket of bytes you actually use. ZFS stripes data across all the vdevs in a pool for performance, which leads to the single most important rule for beginners:

Warning

A pool stripes across its vdevs with no redundancy between them. If a pool has two mirror vdevs and you lose an entire vdev (both disks of one mirror), the whole pool is gone — not half of it, all of it. Redundancy lives inside each vdev, never across them. Add redundancy at the vdev level (mirror or RAID-Z), and never add a bare single-disk vdev to a pool you care about, because that one disk becomes a single point of failure for everything.

Datasets — the filesystems inside the pool

Once you have a pool, you don't format it and mount it like a partition. Instead you carve it into datasets, which are filesystems that all draw from the pool's shared free space. A dataset gets mounted at a path, behaves like any other filesystem to your applications, and can carry its own properties — its own compression setting, its own quota, its own snapshot schedule. You might have tank/home, tank/var-log, and tank/postgres all living in the pool tank, each tuned differently, none of them pre-allocated a fixed size. They grow and shrink against the common pool, which means no more guessing how big to make each partition up front. That flexibility alone wins converts from the rigid world of LVM plus fixed filesystems.

There's also a second kind of dataset called a zvol — a raw block device carved out of the pool, used when you want to hand a virtual machine or an iSCSI target a "disk" rather than a filesystem. You'll meet it eventually; for ordinary server work, plain filesystem datasets are what you reach for.

RAID-Z vs Mirrors — and How It Differs From Classic RAID

ZFS has its own redundancy schemes living inside vdevs, and they rhyme with classic RAID without being identical to it.

Mirror — the equivalent of RAID 1. Two or more disks, each a full copy. Fast, simple, rebuilds quickly because there's no parity to recompute. The default choice for anything latency-sensitive, and the easiest to expand: add another mirror vdev and the pool just gets bigger.
RAID-Z1 — single parity, the cousin of RAID 5. Survives one disk failure per vdev. Usable capacity is roughly (N−1) disks out of N.
RAID-Z2 — double parity, the cousin of RAID 6. Survives two simultaneous failures per vdev. This is the sensible default for any sizeable array, because rebuilds on big disks take long enough that a second failure during the window stops being hypothetical.
RAID-Z3 — triple parity. Survives three failures per vdev. RAID-Z3 has no equivalent in mainstream classic RAID at all; it exists because ZFS targets very wide vdevs and very large disks, where the rebuild window is measured in days and the maths of "what could fail next" gets uncomfortable.

So far that looks like a renamed copy of mdadm. It isn't, and the difference is the part worth understanding, because it fixes the single nastiest failure mode of classic parity RAID.

Classic RAID 5 has a notorious flaw called the write hole. A parity write touches several disks, and if power dies partway through — some disks updated, the parity not yet — the stripe is now internally inconsistent, and the array has no way to know which disk is the liar. Worse, classic RAID rebuilds the entire disk on replacement, sector for sector, even the empty sectors, because the RAID layer underneath has no idea which blocks actually hold data. On a half-empty 16 TB drive, that's hours of pointless work hammering tired survivors.

RAID-Z sidesteps both. Because it's copy-on-write (we'll get there), every write lands as a complete new stripe or not at all — there's no half-updated stripe to leave a hole. And because ZFS is the filesystem, it knows exactly which blocks are live, so a resilver (ZFS's word for a rebuild) copies only real data and skips the empty space. A freshly-installed pool that's 10% full resilvers in a tenth the time a classic array would. The integration that costs you RAM buys you this: the redundancy layer and the filesystem are the same layer, so they never lie to each other.

Note

There's a real constraint that surprises people: a RAID-Z vdev historically could not be grown by adding a single disk — you grew a pool by adding a whole new vdev. RAID-Z expansion (adding one disk to an existing vdev) finally landed in OpenZFS 2.3 in 2024, but it's new, and the old planning habit still rules most deployments: decide your vdev width up front. Mirrors never had this problem — you can always bolt on another mirror pair.

End-to-End Checksums and Self-Healing

This is the heart of ZFS, so let's make it concrete rather than hand-wave it.

Picture the pool's metadata as a tree (it's a Merkle tree, the same structure that underpins Git and blockchains). Every block of data has a checksum, and that checksum is stored in the parent block that points to it — not next to the data, where the same bad write or bad sector could corrupt both at once. The parent block has its own checksum stored in its parent, all the way up to a single root block called the uberblock. Verify the uberblock and you can verify the entire tree beneath it. Nothing on the disk can be quietly wrong without the checksum chain catching it, because to forge a consistent lie you'd have to corrupt the data, its checksum one level up, that block's checksum another level up, and so on to the root — and the odds of random rot producing that exact cascade are effectively zero.

Now the payoff. When ZFS reads a block and the checksum doesn't match, it doesn't just report an error like a traditional filesystem would — it goes looking for a good copy. If the vdev is a mirror, the other disk has one. If it's RAID-Z, the parity can reconstruct it. ZFS hands the correct data to your application, then writes the good copy back over the bad block to heal it. You see a counter tick up in zpool status under CKSUM, and that's the only sign anything happened. The corruption was caught and corrected in flight, transparently, on a running system. This is the thing classic RAID genuinely cannot do: an mdadm array can rebuild a dead disk, but it has no checksums, so it can't tell that a live disk handed back a subtly wrong byte. ZFS can. That gap is the whole reason serious archives and backup targets run on it.

Copy-on-Write — the Trick Under Everything

ZFS never overwrites live data. Change a block and ZFS writes the new version to free space, then updates the pointer to it — and since that pointer lives in a parent block, that gets rewritten too, cascading up to a new uberblock. The old blocks stay exactly where they were until nothing references them. This is copy-on-write (CoW), and almost every headline feature falls out of it for free.

Because the old data is never clobbered, the on-disk state is always consistent — there's no window where the filesystem is half-updated, so ZFS needs no fsck and no separate journal the way ext4 does. A crash mid-write simply means the new uberblock never got committed; on reboot ZFS uses the last good one and the half-written blocks are just unreferenced garbage to be reclaimed. Because the old data is still sitting there, a snapshot costs almost nothing — it's just a note that says "don't free these blocks yet." And because every write goes to a fresh location with a fresh checksum, the integrity tree is always coherent.

CoW does have a cost, and it's the same one btrfs pays: heavy random-write workloads — databases, above all — fragment over time, because a small in-place update becomes a write-somewhere-else-and-repoint operation. On a busy PostgreSQL or MySQL volume you tune around this (a matching recordsize, logbias=throughput, sometimes a separate fast log device), but the principle is the same as on any CoW filesystem: random writes are where the design works hardest.

Snapshots and Clones

A zfs snapshot is a read-only frozen view of a dataset at an instant, and thanks to CoW it's created in well under a second and consumes essentially no space at creation — it grows only as the live dataset diverges from it, holding onto the old blocks the live side has since replaced.

zfs snapshot tank/home@before-upgrade     # freeze tank/home right now
zfs list -t snapshot                       # list snapshots and how much they hold
zfs rollback tank/home@before-upgrade      # revert the dataset to that instant
zfs diff tank/home@before-upgrade          # show what changed since the snapshot

The first time you rollback a botched package upgrade in two seconds flat — no restore, no downtime, just back to how it was before I broke it — you stop thinking of snapshots as a nice-to-have. A clone goes one step further: a writable dataset branched off a snapshot, sharing the unchanged blocks until you modify them, which makes spinning up a copy of a 500 GB database for testing nearly instant and nearly free until the test actually writes something.

There's a second superpower hiding here: zfs send and zfs receive serialise a snapshot (or just the difference between two snapshots) into a stream you can pipe over SSH to another machine. That's incremental, block-level, checksum-verified replication with no extra tooling — the backbone of serious ZFS backup strategies.

The ARC — Why ZFS "Uses All Your RAM" (and Why That's Fine)

Here is the thing that scares every newcomer, and the muddy point this whole page exists to nail clearly, once and for all.

You install ZFS, you run free -h or glance at a memory graph a few days later, and your RAM is gone — 60%, 70% of it "used," on a box that's barely doing anything. The instinct is panic: something's leaking, the server's about to start swapping, I need more memory. Almost always, you need none of those things. What you're seeing is the ARC — the Adaptive Replacement Cache — and understanding it is the difference between trusting ZFS and fighting it.

The ARC is ZFS's in-RAM read cache. Free memory is wasted memory: a page of RAM doing nothing helps no one, so ZFS fills it with recently and frequently used data so the next read is answered from RAM at memory speed instead of from disk at glacial spinning-rust speed. By default the ARC will grow to claim up to half your system memory (you can raise or cap that). It is working, not leaking. And critically, it's reclaimable: the moment a real application asks for memory, ZFS shrinks the ARC and hands it over. The cache is a guest that leaves the instant the host needs the room.

If this sounds familiar, it should — it's exactly the philosophy behind the kernel's own page cache, which does the same thing for ordinary filesystems: borrow idle RAM for caching, give it back on demand. There's one wrinkle that trips up monitoring, though, and it's why ARC earns its own paragraph instead of being lumped in with page cache. On Linux, the kernel's page cache is reported under a tidy buff/cache column that every tool knows to discount as "available." The ARC, because ZFS lives outside the mainline kernel as a separate module, has historically been accounted as plain application memory — SUnreclaim in /proc/meminfo on older builds — so a naive memory check counts it as genuinely used and unavailable. A dashboard that doesn't know about ZFS will show a ZFS box at 80% memory and cry wolf, when 50 of those points are instantly reclaimable cache doing useful work.

Pro Tip

On a ZFS host, read memory pressure from arc_summary and the kernel's own MemAvailable figure (in /proc/meminfo), not from a raw "used vs total" percentage. MemAvailable is the kernel's honest estimate of what an application could actually get its hands on right now, and it correctly treats reclaimable ARC as available. The number that should worry you is not high memory use — that's the cache earning its keep — it's sustained swap activity, which means real pressure that the cache couldn't relieve.

So: high RAM use on a ZFS box is the system working as designed, the same way a page-cache-fat box is healthy, not sick. Cap the ARC if you genuinely need headroom for a fixed-size application (set zfs_arc_max), but don't reflexively fear the number. The cache is the point.

Never Put Hardware RAID Under ZFS

This one is a rule, not a suggestion, and it follows directly from everything above.

ZFS wants raw disks. Its checksums, its self-healing, its honest view of which disk holds the good copy — all of it depends on ZFS seeing each physical drive directly and controlling exactly what gets written where. The moment you put a hardware RAID controller between ZFS and the disks, you blind it. The card presents one fat "virtual disk" to the OS and hides the individual drives behind it. Now when ZFS reads a block and the checksum fails, it asks the controller for a good copy — and the controller, which has its own ideas about redundancy and its own cache, either can't help or hands back whatever it thinks is correct. ZFS can detect the corruption but can no longer heal it, because the redundancy it would use to repair is locked away inside a black box that doesn't share ZFS's notion of truth.

Danger

Do not stack ZFS on top of a hardware RAID volume. Use a plain HBA (host bus adapter) in "IT mode" / JBOD that passes each disk through untouched, and let ZFS do the RAID. A hardware RAID card under ZFS doesn't add safety — it removes the self-healing you bought ZFS for, hides drive failures and SMART data behind the controller, and can corrupt the pool if its write cache lies about a flush during a power loss. If you already have a RAID card, flash it to IT mode or replace it with an HBA. Raw disks, every time.

The same logic means ZFS is also where you stop layering: don't run ZFS on top of mdadm, don't run it on top of LVM. Those layers exist to give dumb filesystems the volume management and redundancy ZFS already has built in. Give ZFS the bare block devices and let it own the stack — that's the whole bargain.

Compression — On by Default, and You Want It

Turn compression on. On almost every dataset, on almost every workload, it is free performance, and the modern defaults make it a genuine no-brainer.

zfs set compression=lz4 tank/data     # the long-time sensible default
zfs set compression=zstd tank/archive # better ratio, still fast; great for cold data
zfs get compressratio tank/data       # see how much you're actually saving

The counterintuitive part: compression often makes things faster, not slower. A disk is glacially slow compared to a CPU. lz4 compresses and decompresses so fast it's nearly free, and because the compressed data is smaller, there are fewer bytes to drag off the platter — so you spend a few CPU cycles to avoid a lot of slow I/O, and come out ahead. lz4 also has an "early abort" that detects already-compressed data (a JPEG, a video) and stops wasting effort on it instantly. zstd (newer, tunable from zstd-1 to zstd-19) trades a little CPU for a noticeably better ratio and shines on archival data you read rarely. The old advice to leave compression off is a relic of slow algorithms on slow CPUs; on a modern box, compression=lz4 is one of the first properties you should set on a new pool.

How I Inspect It

Two commands cover ninety percent of operating a pool, and you read them in order.

zpool status — the health dashboard

zpool status

  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:14:31 with 0 errors on Sun Jun  8 03:14:31 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

errors: No known data errors

Read it top-down. state: ONLINE is the all-clear; DEGRADED means a vdev lost a disk but is still serving (act soon), and FAULTED or UNAVAIL means a vdev — and therefore the pool — is down. The three columns on the right are the ones that matter: READ and WRITE count I/O errors, and CKSUM counts checksum failures — silent corruption that ZFS caught. A non-zero CKSUM on one disk while the pool stays ONLINE is ZFS quietly doing its job: it found bad data and healed it from redundancy. A climbing CKSUM count, though, is an early warning that a disk is failing even if SMART hasn't flagged it yet — ZFS often notices a sick drive before the drive admits it.

zpool list and zfs list — capacity and layout

zpool list                    # pools: size, allocated, free, fragmentation, health
zfs list                      # datasets: used, available, referenced, mountpoint
zfs list -t snapshot          # snapshots and what they're holding onto

zpool list shows raw pool capacity; zfs list shows the per-dataset view your applications actually live in. The two disagree by exactly the parity overhead and any held snapshots — which is the usual answer to "why does the pool say it's full when my data isn't that big": a forgotten snapshot is pinning blocks the live data already deleted.

Scrub — Finding Rot Before It Finds You

A scrub reads every block in the pool, verifies it against its checksum, and repairs anything broken from redundancy. It's a proactive integrity sweep — instead of waiting to read a corrupt block during normal use (or worse, during a resilver, when you're already down a disk), you find and fix rot on your own schedule.

zpool scrub tank              # start a scrub (runs in the background, throttled)
zpool status tank             # watch progress and see what it repaired
zpool scrub -s tank           # stop a running scrub

This is RAID-Z's answer to the classic RAID check you'd trigger via /sys/block/mdX/md/sync_action, but with teeth: mdadm can only tell you a mismatch exists, whereas ZFS knows from the checksum which copy is correct and fixes it. Run a scrub monthly (a cron job or a systemd timer; most distros ship one), and run one immediately after any unclean shutdown or any time the CKSUM counter starts moving.

Cheat Sheet

The commands you'll actually reach for, roughly in the order a pool's life unfolds. Two verbs run everything: zpool manages pools and vdevs, zfs manages datasets and snapshots.

# --- Create pools (vdev type is the word before the disks) ---
zpool create tank mirror sda sdb                      # 2-disk mirror (RAID 1)
zpool create tank raidz sda sdb sdc                   # RAID-Z1 (single parity, ~RAID 5)
zpool create tank raidz2 sda sdb sdc sdd              # RAID-Z2 (double parity, ~RAID 6)
zpool create tank mirror sda sdb mirror sdc sdd       # striped mirrors (like RAID 10)

# --- Inspect ---
zpool status                                          # health, vdev tree, error counts
zpool list                                            # capacity + fragmentation per pool
zfs list                                              # datasets, usage, mountpoints
zfs list -t snapshot                                  # snapshots and what they hold
arc_summary                                           # ARC cache stats (the RAM question)

# --- Datasets ---
zfs create tank/home                                  # a filesystem dataset (auto-mounts)
zfs set compression=lz4 tank/home                     # turn on compression (do this)
zfs set quota=100G tank/home                          # cap a dataset's size
zfs set atime=off tank/home                           # stop updating access times (faster)
zfs get all tank/home                                 # every property on the dataset

# --- Snapshots, clones, replication ---
zfs snapshot tank/home@daily                          # instant frozen view
zfs rollback tank/home@daily                          # revert to it
zfs clone tank/home@daily tank/home-test              # writable branch off a snapshot
zfs send -i @mon tank/home@tue | ssh host zfs recv tank/home   # incremental replicate

# --- Integrity + repair ---
zpool scrub tank                                      # verify + heal the whole pool
zpool replace tank sdb sde                            # swap a dead disk; resilver starts
zpool clear tank                                      # reset error counters after a fix

# --- Import / export (move a pool between machines) ---
zpool export tank                                     # cleanly detach the pool
zpool import tank                                     # reattach it (even on a new host)

Pro Tip

The word right before the disks in zpool create is the redundancy level — mirror, raidz, raidz2, raidz3, or nothing at all. That "nothing at all" is the trap: zpool create tank sda sdb makes a striped, zero-redundancy pool where either disk's death takes everything, and ZFS won't stop you. Always name the vdev type, and double-check zpool status shows mirror or raidz lines and not a flat list of bare disks before you trust the pool with anything.

Gotchas

Things that catch people, roughly in order of how much they sting.

A pool with no redundancy is a time bomb. The most common beginner mistake is zpool create tank sda sdb, expecting a mirror and getting a stripe. ZFS checksums will faithfully tell you a block is corrupt — and then be unable to fix it, because there's no second copy. Checksums detect; redundancy heals. You need both.
ZFS is not a backup. Snapshots and send/receive are wonderful, but a snapshot on the same pool dies with the pool, and rm -rf on a live dataset is faithfully reflected in the live dataset. Send snapshots to another machine and you have a backup; keep them on the same box and you have a convenience.
Don't fill the pool. CoW needs free space to write new blocks, so a ZFS pool slows dramatically and fragments badly above roughly 80% full. Treat 80% as the line, not 95%. This is sharper than the disk-full threshold you'd tolerate on ext4.
Snapshots silently eat your space. A snapshot pins every block the live data has since changed or deleted, so an old, forgotten snapshot can hold gigabytes hostage while zfs list on the live dataset looks innocent. When a pool fills mysteriously, zfs list -t snapshot is the first place to look.
Kernel upgrades can break the module. Because ZFS is built against your running kernel via DKMS, a kernel upgrade has to recompile it — and if that fails, the pool won't import until you fix the build. Pin a known-good kernel, or at least don't reboot into a fresh kernel right before you leave for the weekend.
No shrinking, limited reshaping. Like XFS, a pool doesn't shrink, and until very recently you couldn't widen a RAID-Z vdev at all. Plan your vdev geometry up front; growth means adding whole vdevs.

History and Philosophy

ZFS was built at Sun Microsystems in the early 2000s by Jeff Bonwick, Matt Ahrens, and their team, and shipped in Solaris 10 in 2005. The brief was radical for its day: stop treating the volume manager, the RAID layer, and the filesystem as separate products that distrust each other, and instead design one system that owns the whole stack so it can guarantee integrity end to end. Pooled storage, end-to-end checksums, copy-on-write, cheap snapshots, RAID-Z — they arrived as a coherent package rather than features bolted on over decades. It was, and largely still is, the most ambitious filesystem ever shipped in a mainstream OS.

Then came the licensing knot — and it's worth the detour, because it explains why ZFS on your Linux box looks the way it does.

Backstory

Sun released ZFS under the CDDL (Common Development and Distribution License). The Linux kernel is GPLv2. The two licenses are both open source and both perfectly legitimate — but they are mutually incompatible in a way that legally prevents ZFS code from being merged into the GPL kernel and distributed as one combined work. Many lawyers believe Sun's choice was deliberate: a way to keep ZFS open while ensuring it couldn't simply be absorbed into Linux, Sun's competitor at the time. Oracle's 2010 acquisition of Sun, and its subsequent re-closing of new Solaris ZFS development, froze any chance of a relicense. So the open-source world forked the last open code into OpenZFS, which is what every Linux and FreeBSD user runs today. It lives as a separate kernel module loaded at runtime — never compiled into the mainline tree — which is precisely why your distro ships it via DKMS and rebuilds it on every kernel upgrade. The incompatibility is also the direct reason btrfs was started at Oracle in 2007: Linux wanted ZFS's ideas under a GPL-friendly license it could ship in-tree, and btrfs was the attempt to build them from scratch.

So the practical reality on Linux: you install OpenZFS from your distro's packages (zfsutils-linux on Debian/Ubuntu), it builds a kernel module via DKMS, and from then on it is ZFS — the same code FreeBSD ships, mature and battle-tested on petabytes of production data for two decades. The out-of-tree status costs you the DKMS recompile dance and a small amount of "is my kernel still supported" vigilance. It does not cost you reliability; OpenZFS is rock solid. It's a legal artifact, not a quality one — but it's a legal artifact you operate around every time you patch a kernel, so it's worth knowing exactly why it's there.

The deeper philosophy is the one worth carrying away. Most of Unix storage is built on layers that politely don't look inside each other — and that politeness is exactly what lets silent corruption slip through, because no single layer can see enough to catch it. ZFS's bet was that integrity is not a feature you can add at one layer; it has to be a property of the whole system, from the application's write down to the spinning platter and back. That bet is why it asks for your RAM and your raw disks, and it's why, when your data genuinely matters, there's still nothing quite like it.