UK’s trusted IT infrastructure partner since 2003
Servnet
ConfiguratorGet in Touch
What is ZFS RAIDZ? A beginner's guide (2026) — analysisWhat is ZFS RAIDZ? A beginner's guide (2026) — analysis — reach
Storage · RAID

What is ZFS RAIDZ? A beginner's guide (2026)

Servnet Storage Team · Storage & Data Protection7 min read

RAIDZ is ZFS's software parity — like RAID 5/6 but with checksums, self-healing and no write hole. Here's what makes it different, then size a pool in the ZFS calculator.

A ZFS pool
4Pool (zpool)capacity = sum of vdevs3vdev 1 — RAIDZ2≈ IOPS of one drive2vdev 2 — RAIDZ2adds capacity + IOPS1Driveschecksummed, self-healing

RAIDZ vs traditional RAID

RAIDZ1, RAIDZ2 and RAIDZ3 are single, double and triple parity — broadly the ZFS equivalents of RAID 5, 6 and triple-parity RAID. The difference is that ZFS is a combined filesystem and volume manager, so it knows what every block contains. It checksums all data and metadata, detects silent corruption, and self-heals from parity or another copy during a scrub.

ZFS also uses variable-width stripes and copy-on-write, which eliminates the RAID 'write hole' (the corruption risk when power is lost mid-write in traditional parity RAID). That integrity story is why TrueNAS and many NAS platforms are built on ZFS.

vdevs are the key concept

A ZFS pool is made of one or more vdevs (virtual devices); a RAIDZ vdev is a parity group. You add capacity and performance by adding vdevs. Critically, redundancy is per vdev — losing a whole vdev loses the pool — and a RAIDZ vdev delivers roughly the random IOPS of a single drive, so pool IOPS scale with the number of vdevs, not drive count. See RAIDZ1 vs Z2 vs Z3.

For lots of random IOPS (databases, VMs), use more (narrower) vdevs or mirror vdevs; for capacity, use wider RAIDZ2 vdevs.

RAIDZ vs traditional RAID
RAIDZ1RAIDZ2RAIDZ3≈ traditionalRAID 5RAID 6Triple parityFailures / vdev123ChecksumsYesYesYesWrite holeNoneNoneNone

Real capacity is less than the simple sum

ZFS usable capacity is parity removed, then a ~3.2% slop reservation, then (parity+1)-sector allocation padding — negligible at the default 128 KiB recordsize but significant for small volblocksize (e.g. 8 KiB zvols for VMs). A naïve calculator overstates ZFS capacity; ours models the lot. Keep pools below ~80% full for performance.

Try the ZFS calculator and change recordsize to see padding appear.

Key takeaways
  • RAIDZ1/2/3 = ZFS single/double/triple parity, with checksums, self-healing and no write hole.
  • A pool is built from vdevs; redundancy is per vdev and a lost vdev loses the pool.
  • A RAIDZ vdev has the random IOPS of one drive — scale IOPS with more vdevs.
  • Real usable = parity + ~3.2% slop + (parity+1) padding; keep pools under ~80% full.
Frequently asked

FAQs — What is ZFS RAIDZ? A beginner's guide (2026)

ZFS RAIDZ

Is RAIDZ the same as RAID 5?

Similar idea (single parity, (n−1) usable per vdev), but RAIDZ adds end-to-end checksums, self-healing, copy-on-write and no write hole — and a RAIDZ vdev's random IOPS are limited to about one drive. It's RAID 5's resilience with ZFS's integrity, at a different performance profile.

What is a vdev?

A virtual device — the building block of a ZFS pool. A RAIDZ vdev is a parity group of drives. You grow a pool by adding vdevs; pool IOPS scale with vdev count, and losing any vdev loses the pool.

Why is my ZFS pool smaller than the drives add up to?

Parity, a ~3.2% slop reservation, and (parity+1)-sector padding all reduce usable capacity — padding especially at small recordsize. The ZFS calculator models all three so the figure matches the pool.

Related

Continue reading

More in Storage

Got a question this article didn't answer?

One conversation with an engineer who's done this before. No sales script.

Talk to Servnet →