What it actually is

You're building a NAS, or you're rebuilding one because the last one ate your data. Either way you've read enough forum posts to know that ZFS keeps coming up, and you want to know whether that's for you or for the people who write kernel patches on weekends.

Here's the short version: ZFS is a filesystem and a volume manager in one. That sentence does a lot of work, so let's unpack it before you commit a single disk.

What it actually is

In the classic Linux stack you do two things. First you carve up disks into volumes with LVM, then you format a filesystem like ext4 or XFS on top of those volumes. Two layers, two sets of tools, two places where something can go wrong.

ZFS collapses that. You hand it raw disks, it builds a pool (a zpool), and inside that pool you create datasets that behave like filesystems. No LVM, no mkfs.ext4, no fstab entries you have to reason about. The pool knows about the disks, the datasets know about the files, and the whole thing was designed together instead of bolted together.

That integration is why ZFS people get evangelical. It's also why ZFS is not something you install on a whim.

The integrity thing, which is the real reason people care

Most filesystems assume your hardware works. They assume the disk returns the bytes it was asked for, and if it doesn't, well, that's the disk's problem.

ZFS assumes the opposite. Every block it writes gets a checksum, and that checksum lives in the parent block, not in the block itself. When you read data back, ZFS recalculates and compares. Mismatch means bitrot, a bad cable, a controller lying to you, or a disk quietly returning garbage.

If you have redundancy — a mirror or RAID-Z — ZFS doesn't just notice the corruption. It fetches the correct copy from another disk, repairs the bad block, and carries on. That's self-healing, and it's the feature that turns "I have backups" into "I have backups and I know my backups are intact."

You can get some of this elsewhere. btrfs does checksums and scrubs too. But btrfs has spent years being the filesystem you recommend to people you don't like, and while that reputation has softened, it hasn't vanished.

Why it's a commitment

ZFS wants RAM. Not a polite amount — it wants a lot, and it will take it. The ARC (adaptive replacement cache) is the read cache, and on a busy system it will happily consume most of your memory. You can cap it, but capping it means you're giving up the thing that makes ZFS fast.

Deduplication is the trap here. It sounds great: store duplicate blocks once, save space. In practice dedup needs roughly 5 GB of RAM per TB of storage for the dedup table, and if you get it wrong your pool grinds to a halt. Most people should leave dedup off. The ones who need it already know who they are.

Then there's RAID-Z expansion. For years you couldn't add a single disk to a RAID-Z vdev — you added a whole new vdev or you started over. OpenZFS 2.3 changed that with `raidz_expansion`, but it's recent and not every platform ships it yet. If you're planning to grow one disk at a time, check your version before you build.

The versions that matter

OpenZFS is the codebase you'll actually run. It came out of the 2013 fork after Oracle stopped developing ZFS in the open, and it now covers FreeBSD, Linux, and illumos. Oracle's own ZFS lives on in Solaris and is a separate lineage — good, but not what you'll install on a Linux box.

On Linux, OpenZFS 2.3 is the current line. On FreeBSD, ZFS is in the base system and tends to lag slightly behind OpenZFS releases, which is either reassuring or annoying depending on your temperament. On Ubuntu, `zfs-linux` from the repos is usually a version or two behind upstream; the `zfs` PPA from the OpenZFS project gets you closer to current.

The 128-bit architecture is worth one sentence: the theoretical maximum file and filesystem size is 16 exbibytes. You will not hit it. Nobody will hit it. It's there so the design never has to be revisited.

What it costs you in practice

ECC memory is the recommendation, not a hard requirement. The argument is that ZFS trusts RAM, and non-ECC RAM can corrupt data before the checksum is ever computed. That's true. It's also true for every other filesystem, which just doesn't tell you when it happens. If you're building a serious pool, buy ECC. If you're building a homelab on a budget, know what you're accepting.

Snapshots are cheap and you should use them. A snapshot stores only what changed since the last one, and taking one is nearly instant. Clones are writable copies of a snapshot using copy-on-write, so they cost nothing until you start modifying them. This is where ZFS quietly replaces half your backup scripts.

Compression is on by default on most modern installs (lz4 or zstd) and costs you almost nothing in CPU for a real gain on text-like data. Turn it on and forget it.

The default recordsize is 128 KB. That's fine for general use. Databases and lots of small files often do better with a smaller recordsize, and large sequential workloads do better with larger. You tune this per dataset, not per pool, which is the point of datasets.

Where it stops being the obvious answer

If you have one disk and no redundancy, ZFS gives you checksums and snapshots and not much else. The self-healing needs a second copy to heal from. Single-disk ZFS is a reasonable choice for the snapshotting alone, but don't tell yourself you're protected.

If you have very little RAM, or you're running on a small VPS with 1 GB, ZFS will work but it won't be pleasant. ext4 or XFS will do the job with less overhead and fewer opinions.

If you want the simplest possible thing that stores files, ZFS is not that. It's a system with a vocabulary — pools, vdevs, datasets, ashift, recordsize — and you'll need to learn it. The learning curve is real. The payoff is that once you understand it, storage stops being a thing you worry about.

The part nobody puts in the README

The reason to run ZFS isn't performance, though it's fast. It isn't features, though it has more than you'll use. It's that ZFS was designed by people who assumed things break, and then built the system so that when they do, you find out before you lose data instead of after.

That's a different posture than most storage software takes. It's also why ZFS people are insufferable about it.

The honest summary: run ZFS if you have redundant disks, enough RAM, and the patience to learn a pool layout before you type the first command. Skip it if you're on a single disk, tight on memory, or you want storage to be a checkbox rather than a skill. Both of those are legitimate answers, and only one of them is yours.