TrueNAS Pool Capacity Calculator
Estimate TrueNAS pool capacity for mirrors and RAIDZ. Compare parity, padding, a fixed slop allowance and an 80% planning ceiling before buying disks.
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. - Slop allowance + 80% target: this model deducts a fixed
1/64(~1.56%) allowance, then applies an 80% planning target. Actual OpenZFS reserve accounting depends on the release and settings. "Safe @ 80%" describes this capacity budget; it does not guarantee workload performance or data safety.
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 depend on the workload. Treat "Estimated usable" as an approximation and "Safe @ 80%" as your planning figure. Mixed disk sizes in one RAIDZ vdev are modeled at the smallest disk, exactly as ZFS does.
The explanation and official references below describe this model's assumptions
(v1.2.0). Verify the real system with
zpool list / zfs list on the built pool.
How to read the TrueNAS pool capacity estimate
Start with the number of disks that will hold pool data, their advertised capacity, and the layout of each vdev. A vdev is one redundancy group; the pool combines those groups. The builder models equal-sized members within each group. If your disks differ, enter the smallest member's size. Keep boot devices, spares and cache devices outside the data-vdev count so their capacity does not inflate the estimate.
Parity changes the starting capacity
The OpenZFS pool concepts manual gives the approximate RAIDZ capacity as disk count minus parity count, multiplied by disk size. A six-drive RAIDZ2 group of 8 TB drives therefore starts at 32 TB after parity: four drive-equivalents hold data and two provide parity. Parity is distributed across the drives; there are no dedicated parity disks to identify or remove from this vdev.
A two-way mirror holds one copy's worth of usable data, so two 8 TB drives start at 8 TB. Three separate mirror pairs start at 24 TB. Choose between these layouts using RAIDZ vs mirrors, which considers workload and recovery alongside capacity. Fault tolerance applies within each vdev; losing a required data vdev can lose the pool.
TB and TiB describe the same bytes differently
An advertised terabyte is a trillion bytes; a tebibyte is 2 to the power of 40 bytes. Dividing gives about 0.9095 TiB per TB. The 32 TB starting figure above is therefore about 29.10 TiB before the model's reserve deduction. That unit conversion does not consume storage. The TrueNAS ZFS primer explains why advertised drive capacity and displayed capacity differ.
Why ashift padding depends on block size
The OpenZFS ashift property describes sector alignment as a power of two: ashift 12 corresponds to 4096-byte sectors. RAIDZ allocates whole sectors and rounds allocations, so capacity also depends on block sizes and vdev width. This calculator approximates rounding for a 128 KiB record. It does not simulate every block in a real dataset.
Small records, zvol block sizes and compressed blocks can produce different overhead. Use the ashift selector to explore that assumption, not to justify choosing a sector alignment smaller than the drive needs. For the default six-drive RAIDZ2 example, the model's 32 data sectors plus 16 parity sectors already divide evenly into its allocation unit, so it applies no additional padding penalty.
Slop reserve and the 80% ceiling are separate allowances
OpenZFS keeps some space unavailable to ordinary writes to avoid exhausting the pool completely. Its module-parameter reference documents spa_slop_shift with an upstream default of 5, corresponding to 1/32 before other limits. The widget uses a fixed 1/64 allowance for planning instead. That simplified deduction is not a prediction of the exact reserve on your installed TrueNAS version.
With that allowance, the example falls from about 29.10 TiB to 28.65 TiB. Applying the separate 80% planning ceiling gives roughly 22.92 TiB for the data budget. The remaining 20% is headroom you choose to preserve, not another parity loss. The TrueNAS hardware guide recommends leaving free space; the point at which performance suffers still depends on workload and fragmentation.
Budget for snapshots, growth and recovery
A snapshot initially shares blocks with live data, then retains older blocks as files change. That consumption is not a fixed percentage a calculator can know. Plan retention with the snapshot and replication guide and leave room for application growth. Metadata and actual allocation behavior also make the running pool's figures differ from this estimate. Compression savings are deliberately excluded.
Model a new layout separately from an expanded one. TrueNAS RAIDZ extension preserves existing blocks' earlier data-to-parity ratio; the widget estimates a fresh layout. Check the pool expansion options before treating an added disk as equivalent to rebuilding the entire vdev. A spare can help start recovery sooner, but it neither adds usable space nor increases parity.