ZFS offers single, double and triple parity per vdev — RAIDZ1, RAIDZ2 and RAIDZ3. The right one depends on vdev width and drive size. Size any of them, with real ZFS slop and padding modelled, in the ZFS calculator.
How they differ
RAIDZ1 keeps one parity per vdev (survives one failure), RAIDZ2 keeps two (survives two), and RAIDZ3 keeps three (survives three). Usable capacity per vdev is (drives − parity) × drive size, before ZFS overheads. More parity means more resilience and less usable space.
Crucially, fault tolerance is per vdev: a pool of several vdevs loses everything if any one vdev exceeds its parity. Adding vdevs adds IOPS and capacity, not extra protection for an individual vdev.
The resilver factor
Like hardware RAID, single-parity RAIDZ1 has no redundancy left while a failed drive resilvers — a second fault or a bad block on another disk during that window loses the vdev. On large drives, resilvers take many hours or days, so RAIDZ2 (which keeps a parity in reserve) is the recommended default for wide vdevs.
RAIDZ3 keeps two parities in reserve during a single-drive resilver, which matters on very wide vdevs of huge drives where the resilver window stretches into days.
ZFS-specific overheads
ZFS reserves about 3.2% slop and rounds every allocation up to a multiple of (parity+1) sectors. At the default 128 KiB recordsize that padding is usually negligible; at small volblocksize (e.g. 8 KiB zvols for VMs) it can waste a large fraction of capacity — the calculator shows this when you change recordsize.
Performance note that trips many people up: a RAIDZ vdev delivers roughly the random IOPS of a single drive, regardless of width. Pool IOPS scale with the number of vdevs, so for IOPS-heavy work use more (narrower) vdevs or mirrors.