1 · Choose a RAID level
Double-parity ZFS vdev. Min 3 drives; 4+ typical.
2 · Configure drives
3 · Drive class
3.5" nearline SAS/SATA capacity HDD — indicative figures.
Advanced — read/write mix, URE rate, ZFS tuning
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.
Why a naïve RAIDZ figure is usually wrong
A simple “(drives − parity) ÷ drives” figure overstates real ZFS usable capacity, because ZFS adds overheads a hardware-RAID calculator never sees. This tool models the full picture so your pool plan matches what the pool actually reports.
Parity per vdev
Each RAIDZ vdev loses its parity drives — 1 (Z1), 2 (Z2) or 3 (Z3) — to redundancy.
~3.2% slop space
ZFS reserves about 1/32 of the pool so the copy-on-write filesystem can free space when nearly full.
(parity+1) padding
Allocations round up to a multiple of (parity+1) sectors — negligible at 128 KiB, costly at small volblocksize.
80% fill rule
Keep a pool below ~80–90% for performance; we show a recommended usable figure at your chosen fill.
The IOPS rule everyone gets wrong
A RAIDZ vdev delivers roughly the random IOPS of one drive, regardless of how wide it is. Pool IOPS scale with the number of vdevs, not the total drive count — so for IOPS-heavy work, use more (narrower) vdevs or mirrors. Sequential throughput, by contrast, does scale with data disks. The calculator applies this correctly.
ZFS sizing — common questions
How is ZFS RAIDZ usable capacity calculated?
Per vdev, usable capacity is (drives − parity) × drive size — so RAIDZ2 is (n−2) × size. ZFS then reserves about 3.2% slop space, and rounds each allocation up to a multiple of (parity+1) sectors. At the default 128 KiB recordsize that padding is usually negligible, so the headline matches the simple parity figure; at small volblocksize (e.g. 8 KiB zvols) padding can cost a large fraction of capacity. This calculator models all of it.
What is ZFS slop space?
ZFS holds back roughly 1/32 (~3.2%) of the pool so a copy-on-write filesystem can still free blocks when nearly full. It is a small reservation that varies slightly by ZFS version; we surface it as an estimate. Separately, the practical guidance is to keep a pool below 80–90% full for performance — the calculator shows a recommended usable figure at your chosen fill target.
Why does adding drives to a vdev not increase IOPS?
Because a RAIDZ vdev spreads each block across all its data disks, it delivers roughly the random IOPS of a single drive — no matter how wide the vdev is. Pool IOPS therefore scale with the number of vdevs, not the drive count. For more IOPS, add more (narrower) vdevs, or use mirror vdevs.
RAIDZ1 vs RAIDZ2 vs RAIDZ3 — which should I use?
RAIDZ1 (single parity) suits small, narrow vdevs of modest drives. RAIDZ2 (double parity) is the recommended default for wide vdevs of large drives — it keeps a parity in reserve during a resilver. RAIDZ3 (triple parity) is for very wide vdevs of huge drives with multi-day resilver windows. Mirrors are best when you need maximum IOPS.
How much does ashift and recordsize affect capacity?
ashift sets the sector size (512 B vs 4 KiB). On 4 KiB sectors with a small recordsize/volblocksize and certain vdev widths, the (parity+1)-sector rounding wastes extra space to padding. Large recordsize (128 KiB default) minimises this. Switch ashift and recordsize in the calculator to see the effect on your layout.
Does this show pricing?
No — we do not publish prices. Get the full ZFS sizing here, then enter your email for itemised pricing on the drives and server to build it. Servnet is a 24-year UK reseller and confirms the final spec on quote.