ZFS Pool Capacity & Redundancy Calculator
Model real usable Proxmox VE pool capacity — RAIDZ parity, ashift padding overhead, the ZFS slop reserve, and the 80% fill ceiling — not the naive (n-p)*size guess.
Your pool
Support devices & tuning (optional)
Capacity & redundancy
Methodology & honest caveats
Usable capacity here is an engineering approximation, deliberately more conservative than the
textbook (n − p) × disk_size you see in most calculators. That naive formula ignores three real
sources of loss this tool models:
- RAIDZ parity: each RAIDZp vdev of n disks loses a
p/nfraction of raw to parity (the data fraction is(n − p)/n). - ashift padding: ZFS splits every record into data + parity sectors and rounds the total
up to a multiple of
(p + 1)sectors. On the default 128 KiB record atashift=12(32 sectors/record) the loss is small; it grows with wider sectors and parity. We apply a deflation factor from the sectors-per-record table inzfs-constants.jsonrather than assuming zero padding. - ZFS slop + 80% rule: OpenZFS permanently reserves
1/64(~1.56%) as slop so the pool can still free space when full, and RAIDZ/CoW fragmentation makes the practical ceiling ~80%. "Safe @ 80%" is what you should actually plan against.
Drive vendors sell in decimal TB; ZFS reports binary TiB. We convert at the documented TiB/TB ratio. We do not fold in pool metadata, spacemaps, ditto blocks or snapshot churn — those are workload-dependent (often another 1–3%) and lumping them in would hide the inspectable parity/padding model. Treat "Usable (ZFS)" as a slightly optimistic upper bound and "Safe @ 80%" as your planning figure. Mixed disk sizes in one RAIDZ vdev are modeled at the smallest disk, exactly as ZFS does.
Constants & sources are in src/data/zfs-constants.json
(model v1.2.0). This is decision-support, not a guarantee — always verify with
zpool list / zfs list on the built pool.