ZFS

Most filesystems trust the disk. ZFS wants a receipt for every block.

The short answer

ZFS is a filesystem and a volume manager in one. It stores a checksum for every block it writes, and when the pool has redundancy (a mirror or RAID-Z), it repairs a damaged block from a good copy [3][4]. Our assessment: ZFS is a good fit for a NAS or file server where silent corruption would hurt, and it is no substitute for a backup. For a single-disk desktop it is rarely worth the learning curve.

How it works

1. One layer instead of three. Disks become virtual devices (vdevs), vdevs form a pool, and datasets (filesystems or volumes) draw space from that pool [5]. The pool stripes data across all its top-level vdevs. Redundancy lives inside a vdev, not across vdevs: lose one top-level vdev and you lose the pool [5].
2. Copy-on-write. ZFS never overwrites a block that is in use. It writes the changed data to free space, then writes new parents up the tree and finally a new root block, the uberblock. That last switch is one atomic write, so the pool stays consistent after a power cut and needs no fsck [1]. Snapshots are cheap for the same reason: the old tree is still intact [1].
3. Checksums in the parent. Each block pointer stores the checksum of the block it points to, so a damaged block cannot vouch for itself [1]. The checksum property defaults to on, which means fletcher4 in the documentation we read on 25 Oct 2026 (it says this may change). Turning checksums off is "NOT a recommended practice" [2]. A checksum error on read triggers a repair when a good copy exists [3][4].
4. Scrub. zpool scrub reads all data in a pool, verifies every checksum and repairs damage from redundancy. A resilver only looks at data known to be out of date, for example after a disk swap [6].
5. What ZFS cannot do. No technique in ZFS protects against bit flips in RAM, which is why the OpenZFS hardware guide recommends ECC memory [7]. The same guide says hardware RAID controllers should not be used with ZFS, so give it the raw disks [7]. A pool without redundancy can detect corruption but not repair it, and the documentation calls that layout "strongly discouraged" [4]. Snapshots live inside the pool and share its fate. Our assessment: keep a separate backup.

A homelab example

Our inventory (as of 14 to 16 Oct 2026) does not record ZFS on any Bytearium system, so this is a generic walk-through, not a report from our racks. Take two spare disks you are happy to wipe and create a mirrored pool, using stable device names [8]:

sudo zpool create tank mirror /dev/disk/by-id/DISK_A /dev/disk/by-id/DISK_B
sudo zfs create tank/media
sudo zpool scrub tank
zpool status tank

The mirror keyword in zpool create is the documented syntax [4]. zpool status shows scrub progress and what was repaired [6]. Before you ever grow a pool, preview it with zpool add -n: if the pool has a RAID-Z vdev, no top-level vdev can be removed later [8].

Checklist

• Check whether you need checksums and snapshots at all; a single disk with a good backup may be enough.
• Give ZFS whole disks and skip hardware RAID in between [4][7].
• Decide on redundancy before you create the pool: mirror or RAID-Z.
• Preview every zpool add with -n first [8].
• Run a scrub on a schedule and read zpool status afterwards.
• Plan ECC memory for data you cannot recreate [7].
• Keep a second copy outside the pool (3-2-1).