ZFS Pool Capacity & Redundancy Calculator

Model real usable TrueNAS pool capacity — RAIDZ parity, ashift padding overhead, the ZFS slop reserve, and the 80% fill ceiling — not the naive (n-p)*size guess.

Pool design is the one TrueNAS decision you cannot cheaply undo. You cannot remove a RAIDZ vdev or change its width after creation — you would have to destroy and rebuild the pool. Model it here before you buy disks. Every number below is computed in your browser; nothing is sent anywhere.

Your pool

Support devices & tuning (optional)

Hot spares Idle disks auto-resilvered on failure. Not counted as usable capacity. Disk size for spares (TB) A spare must be ≥ the largest disk it may replace. SLOG deviceSeparate ZIL — only speeds up sync writes. Does not add capacity. L2ARC deviceRead cache. Costs a little RAM for headers. Does not add capacity. Special vdev (metadata / small-block)Must be redundant — its loss destroys the pool. Capacity here is metadata-only and excluded from the usable estimate. ashift (sector size) Wider sectors → more RAIDZ parity/padding rounding loss on the default 128 KiB record.

Capacity & redundancy

Raw (all disks)

—

Usable (ZFS)

—

Safe @ 80%

—

Storage efficiency

—

Usable data Parity + padding ZFS slop reserve 80% headroom (free, not lost)

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 RAIDZ_p vdev of n disks loses a p/n fraction 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 at ashift=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 in zfs-constants.json rather 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.

Your pool

Capacity & redundancy

Methodology & honest caveats

Related tools in this network