ZFS RAIDZ Calculator
For ZFS storage pools, parity and metadata take a larger bite out of raw capacity than most RAID calculators show — the ZFS RAIDZ Calculator accounts for all of it. Enter the RAIDZ Level, Number of Drives per vdev, Drive Capacity, and Number of vdevs, then click Calculate to see total pool usable capacity, raw capacity, overhead percentage, fault tolerance per vdev, and a RAIDZ level comparison table for your current drive configuration.
vdev Type, Drive Count, Capacity and ashift: ZFS Pool Inputs
Usable Capacity, Parity Overhead and Data Drives After RAIDZ
Usable Capacity
Raw Capacity
Overhead
Fault Tolerance
| Metric | Value |
|---|---|
| vdev type | — |
| Drives per vdev | — |
| Number of vdevs | — |
| Total drives | — |
| Usable per vdev | — |
| Total usable (pre-ZFS overhead) | — |
| Estimated usable after ZFS overhead (~5%) | — |
| Recommended max data (80% rule) | — |
| Overhead percentage | — |
RAIDZ1, RAIDZ2 and RAIDZ3: Parity Disks, Overhead and Fault Tolerance
| RAIDZ Level | Min Drives/vdev | Parity Drives | Fault Tolerance | Usable per vdev (current config) | Overhead % | Best For |
|---|---|---|---|---|---|---|
| Stripe | 1 | 0 | None | — | 0% | Temp data, scratch pools |
| Mirror | 2 | N-1 | N-1 drives | — | — | Critical data, high read performance |
| RAIDZ1 | 3 | 1 | 1 drive per vdev | — | — | General storage, low-cost |
| RAIDZ2 | 4 | 2 | 2 drives per vdev | — | — | Enterprise storage, large drives |
| RAIDZ3 | 5 | 3 | 3 drives per vdev | — | — | Highest redundancy, archive storage |
How ZFS Allocates Capacity Across vdevs, Drives and Parity
ZFS RAIDZ is a software RAID implementation built into the ZFS filesystem that eliminates the RAID-5 write hole vulnerability present in traditional hardware and software RAID. Unlike standard RAID 5 or RAID 6, RAIDZ uses variable-width stripes that always span all drives in the vdev, with each stripe containing exactly one parity unit. This means ZFS RAIDZ never writes partial stripes, eliminating the need for a non-volatile cache (NVRAM) to protect against partial stripe writes during a power failure. ZFS usable capacity calculations follow the same basic math as traditional RAID, but RAIDZ has specific performance characteristics and optimal vdev sizing rules that differ from hardware RAID arrays. Learn more: compare ZFS RAIDZ vs traditional RAID overhead.
ZFS storage pool capacity is organised into vdevs (virtual devices), and multiple vdevs can be combined in a zpool to increase total capacity. A ZFS pool can contain RAIDZ1 vdevs (1 parity drive), RAIDZ2 vdevs (2 parity drives), RAIDZ3 vdevs (3 parity drives), mirror vdevs (N-way mirroring), and stripe vdevs (no redundancy, like RAID 0). The total pool usable capacity equals the sum of usable capacity across all vdevs. For optimal RAIDZ performance, vdev size should follow a power-of-2-plus-parity pattern — RAIDZ1 vdevs work best at 3, 5, or 9 drives; RAIDZ2 at 4, 6, or 10 drives; RAIDZ3 at 5, 7, or 11 drives. Related: Plan total storage capacity requirements.
ZFS metadata and internal bookkeeping consume approximately 2–5% of raw pool capacity for typical workloads. Snapshots, deduplication tables, and ZFS Intent Log (ZIL) can consume additional space beyond what is shown as usable in a ZFS pool. When planning ZFS storage capacity, add at least 20% headroom above your expected data volume — ZFS performance degrades significantly when pool utilisation exceeds 80%, because the block allocator struggles to find contiguous free space for new writes, increasing fragmentation and reducing write throughput on spinning media. See also: estimate RAID rebuild time and data risk window.
ashift, Sector Alignment and ZFS Pool Expansion Caveats
ashift Setting: ZFS ashift should match the physical sector size of your drives: ashift=9 for 512-byte sectors, ashift=12 for 4K native drives (most modern HDDs and SSDs). Wrong ashift causes write amplification — set it correctly at pool creation as it cannot be changed later.
80% Rule: Never fill a ZFS pool beyond 80% capacity. ZFS uses copy-on-write and needs free space for its block allocator to work efficiently. Above 80%, fragmentation causes severe write performance degradation on spinning media.
Snapshot Space: ZFS snapshots share blocks with the live filesystem. As data changes, snapshots grow. A heavily snapshotted pool can silently fill to capacity even when apparent data usage appears low.
RAIDZ vs Mirror: Mirror vdevs offer significantly better random read and rebuild performance than RAIDZ. RAIDZ offers better capacity efficiency. For databases and VMs, mirror vdevs are preferred. For archival NAS, RAIDZ2 is preferred.
dRAID: OpenZFS 2.1+ introduces dRAID, a distributed spare RAIDZ variant that enables faster rebuilds by spreading the hot spare across all drives in the vdev, enabling parallel rebuild. Use dRAID for large vdevs with many drives.