RAIDZ3 calculator

Triple-parity ZFS — survives three failures per vdev. Set your drives below for live usable capacity, fault tolerance, IOPS, rebuild time and URE risk.

1 · Choose a RAID level

Stripe & mirror

Single parity

Dual / triple parity

Nested

ZFS RAID-Z

Triple-parity ZFS vdev. Min 4 drives; 5+ typical.

2 · Configure drives

vdevs (RAIDZ groups)

Drives / vdev

Pool total: 8 drives · random IOPS scale with vdev count, not width.

Capacity per drive (TB)

3 · Drive class

3.5" nearline SAS/SATA capacity HDD — indicative figures.

Advanced — read/write mix, URE rate, ZFS tuning

Workload mix: 70% read / 30% writeDrive URE rate

Sector size (ashift)

Record / volblocksize

RAID-Z3 · 8 × 16 TB

73.14 TB usable

of 128 TB raw · 57.14% efficiency

Fault tolerance3 per vdev (up to 3 if spread); an 4th loss in any vdev loses the pool

Write penaltyCopy-on-write

IOPS estR ≈120 · W ≈120 · mix ≈120

Throughput estR ≈1K · W ≈1K MB/s

Rebuild / drive est≈ 55.6 h

URE on rebuild risk59.2%

ZFS @ 80% fill56.69 TB

With redundancy still remaining during a single-drive rebuild, a URE here is reconstructed (recoverable) — not data loss. Data loss requires a concurrent second failure. Figure shown is the chance of encountering a URE.

Calculated for planning. We don't publish prices — a 24-year UK reseller, Servnet confirms the exact drives, array and pricing on quote. IOPS, throughput & rebuild are indicative estimates.

Overview

What RAIDZ3 is

RAIDZ3 is ZFS’s triple-parity vdev: usable capacity is (drives-per-vdev − 3) × drive size per vdev, and each vdev survives three simultaneous failures. It is built for very wide vdevs of large, slow drives, where long resilver windows make a third parity worthwhile.

As with all RAIDZ, this calculator models slop, (parity+1) padding and the per-vdev IOPS rule. RAIDZ3 trades the most capacity to parity of any ZFS level, so it is reserved for archival and cold-bulk pools where resilience during multi-day resilvers outweighs efficiency.

At a glance

Usable (per vdev)(drives − 3) × drive size, less slop/padding

Minimum drives5 typical (4 valid)

Fault tolerance3 per vdev

Random IOPS≈ one drive per vdev

Worked example

1 vdev × 8 × 16 TB (128 KiB) → 80 TB usable before slop, survives 3

A single RAIDZ3 vdev of eight 16 TB drives gives 80 TB usable and tolerates three failures — with two parities still protecting the data while a failed drive resilvers, which is the point on drives that take days to rebuild.

Advantages

Survives three failures per vdev
Two parities still in reserve during a resilver
Best resilience for very wide vdevs of huge drives
Full ZFS data-integrity features

Trade-offs

Three drives of parity per vdev — lowest efficiency
Random IOPS ≈ one drive per vdev
Overkill for narrow vdevs
Long resilvers on very large drives

Best for

Very wide vdevs (10–16+) of large nearline drives
Cold / archival bulk pools
Where multi-day resilver windows are a risk

Consider another level when

Narrow vdevs (RAIDZ2 is enough)
IOPS-heavy workloads
Capacity-sensitive deployments

Compare other levels

RAIDZ2 →RAIDZ1 →RAID 60 →All levels →

RAIDZ3 — common questions

How is RAIDZ3 usable capacity calculated?

Per vdev it is (drives − 3) × drive size, less the ~3.2% slop and (parity+1)-sector padding. Eight 16 TB drives in one RAIDZ3 vdev give (8−3) × 16 = 80 TB usable before slop.

When is RAIDZ3 worth the extra parity?

On very wide vdevs of large drives where a resilver takes days. With three parities, two are still held in reserve while one failed drive rebuilds, making a multi-failure event during the long resilver window survivable.

Is RAIDZ3 overkill for a home NAS?

Usually yes. For typical 6–8 drive home pools, RAIDZ2 gives a better capacity/resilience balance. RAIDZ3 earns its keep on wide enterprise vdevs of high-capacity disks.