MB Networks
TOOL-22 · Storage
ZFS pool capacity calculator
Pick a vdev layout and drive count, see usable capacity, parity overhead, and how many drives can fail before the pool goes down.
Usable capacity
0TB
Raw capacity
0TB
Parity overhead
0%
Drives can fail per vdev
0
ZFS keeps writing past ~80% full but fragmentation and performance both degrade — plan usable capacity as your real ceiling for planning purposes, not the number to fill to.
Why usable capacity isn't raw capacity minus a fixed percentage
Parity overhead in a RAIDZ vdev scales with drive count, not a flat percentage — one parity drive's worth out of 4 drives is a 25% tax, but the same one parity drive out of 12 is only about 8%. That's why wider vdevs (more drives each) are more capacity-efficient per redundancy level, at the cost of a longer resilver and more data exposed if a second drive fails during that rebuild.
Mirrors trade capacity for resilver speed
A mirror vdev always yields exactly one drive's worth of usable capacity per vdev, regardless of how many drives are in the mirror — the appeal is a resilver that's just a straight copy from the surviving mirror, dramatically faster than reconstructing a wide RAIDZ vdev from parity. For latency-sensitive workloads (databases, VM storage), that speed is often worth more than the capacity a RAIDZ layout would recover.
How many vdevs can I add to one pool?
As many as you want, and ZFS stripes data across all of them like a RAID 0 of vdevs — the pool's total usable capacity is the sum of each vdev's usable capacity. The tradeoff: losing an entire vdev (more failures than its parity tolerates) loses the whole pool, not just that vdev's data.
Can I mix vdev types in one pool?
Technically yes, but it's not recommended — a pool's overall resilience is only as strong as its weakest vdev, so mixing a mirror and a RAIDZ1 vdev in one pool means the RAIDZ1 vdev is still the failure point that can take the whole pool down. Keep vdev types consistent within a pool.
Why does everyone say not to fill a ZFS pool past 80%?
ZFS is copy-on-write, and as free space shrinks, it has to search harder for contiguous free blocks — write performance and fragmentation both get measurably worse well before the pool is technically full. Planning for 80% as your real usable ceiling avoids that cliff.
Related tools
Storage
NAS / RAID Storage Calculator
Calculate usable capacity for RAID 0/1/5/6/10, ZFS RAIDZ1/2/3, Unraid, SHR, and SHR-2. Supports equal and mixed drive sizes.
Open →Storage
Storage Capacity Growth Forecaster
Enter current usage and a growth rate to see when storage hits a full threshold — months remaining, a projected date, and a month-by-month table.
Open →Storage
RAID Rebuild Time Estimator
Enter your drive size, RAID type, and throughput to estimate rebuild time and your risk window. Includes presets for common NAS drives.
Open →