ZFS Capacity Calculator

Vdev layout:

Choose Mirror, RAID-Z1, RAID-Z2, or RAID-Z3 for this pool estimate.

Disks per vdev:

Enter disks in each matching vdev, such as 2 for mirrors or 8 for RAID-Z2.

Vdev count:

Use 1 for a single RAID-Z group or more for striped mirrors/RAID-Z groups.

Disk size:

Enter one drive size, for example 18 TB or 16 TiB.

Slop handling:

Auto uses OpenZFS 1/32 with bounds; Manual accepts your percent.

Manual slop:

Enter 0-25% of padding-aware capacity.

Recordsize assumption:

Select the dataset recordsize used for the padding estimate, e.g. 128 KiB.

Sector size assumption:

Choose 512 B, 4 KiB, 8 KiB, or 16 KiB to match the pool ashift.

Operating reserve:

Enter 0-40% extra headroom after ZFS slop.

Primary output unit:

Choose the leading display unit; paired decimal/binary values remain visible.

Target planned max used:

Leave 0 to disable; enter a target such as 100 TiB or 120 TB.

Per-disk reserve profile:

Choose none, 2 GiB per disk, or Custom for platform carveouts.

Custom per-disk reserve:

Enter reserve per disk, such as 2 GiB; keep below physical disk size.

Special vdev carveout:

Enter 0-50% expected for metadata or small blocks; it does not reduce namespace.

Stage	Value	Planning context	Copy
{{ row.label }}	{{ row.value }}	{{ row.note }}

Layout	Planned max used	Delta vs current	Raw yield	Fault budget	Target fit	Capacity signal	Copy
{{ row.label }}	{{ row.plannedMaxUsed }}	{{ row.delta }}	{{ row.rawYield }}	{{ row.faultTolerance }}	{{ row.targetFit }}	{{ row.capacitySignal }}

Path	Outcome	Planning note	Copy
{{ row.label }}	{{ row.value }}	{{ row.note }}

Signal	Reading	Copy
{{ row.label }}	{{ row.value }}

Item	Value	Copy
{{ row.label }}	{{ row.value }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

ZFS capacity planning is the point where a disk purchase turns into a pool design. The raw label on the drives is only the starting inventory. The useful planning number depends on how those drives are grouped into top-level vdevs, how much redundancy each vdev carries, how small writes are laid out, and how much space is intentionally left unused so the pool does not run at the edge of full.

The main vocabulary is worth separating early. A vdev is the redundancy unit inside a ZFS pool. A mirror vdev stores the same block on two or more members, so adding extra mirror members improves the copy cushion but does not increase data capacity inside that vdev. A RAID-Z vdev spreads data and parity across all members. RAID-Z1, RAID-Z2, and RAID-Z3 reserve one, two, or three parity sectors per stripe and can tolerate that many device failures inside the vdev before the vdev is lost.

Common ZFS vdev layouts and capacity planning meaning
Layout	Capacity planning meaning	Main tradeoff
Mirror	One member's worth of data capacity per mirror vdev.	More copies improve fault cushion, not namespace size.
RAID-Z1	Single-parity RAID-Z group.	Higher yield, but a narrow failure margin during resilver.
RAID-Z2	Double-parity RAID-Z group.	Common balance for capacity pools and general NAS use.
RAID-Z3	Triple-parity RAID-Z group.	More parity protection with a larger capacity cost.

ZFS capacity planning flow from raw disks through data, parity, reserve, and planned headroom

RAID-Z capacity is not always the simple data disks divided by total disks ratio shown in many napkin estimates. Small records on wide RAID-Z vdevs can require extra sectors because data and parity have to land on disk-sector boundaries. The dataset recordsize and the vdev ashift value, which represents the smallest allocation unit as 2 to the ashift power, can therefore change a padding-aware estimate.

Unit choice also changes how numbers feel. Drive labels are usually decimal TB, while many operating systems report binary TiB. A 14 TB drive is about 12.73 TiB before any ZFS layout cost is subtracted. Capacity planning should also reserve space for slop, snapshots, allocator behavior, and growth. Compression may make a dataset appear to hold more logical data, but it should not be treated as guaranteed purchase capacity unless the workload is well measured.

A ZFS sizing estimate can support hardware planning, quota design, and layout comparison, but it cannot prove pool health or resilver safety by itself. The result is most useful when the same assumptions are kept fixed while comparing mirror width, RAID-Z parity, disk size, vdev count, recordsize, and operating reserve.

How to Use This Tool:

Start with the physical pool shape you are considering, then adjust the advanced assumptions only when they match the platform or workload you actually plan to run.

Choose Vdev layout, Disks per vdev, and Vdev count. The summary will show Planned max used capacity for that topology, plus badges for status, layout, fault cushion, raw yield, and slop.
Enter one Disk size and choose the matching unit. Use TB for drive label sizes and TiB when you are matching an existing report that already uses binary units.
Set Slop handling and Operating reserve. OpenZFS auto slop uses the modeled 1/32 reservation with 128 MiB and 128 GiB bounds, while the operating reserve is the headroom you choose after slop.
For RAID-Z layouts, set Recordsize assumption and Sector size assumption. The RAID-Z padding loss line in the Capacity Ledger changes when smaller records or larger sectors consume extra partial-stripe space.
Open Advanced for Target planned max used, Per-disk reserve profile, Special vdev carveout, and Primary output unit. Use the target field when you need the Target Fit Paths table to compare layout changes, vdev expansion, or larger disks.
If the summary says Check inputs, fix the vdev width, disk size, or per-disk reserve first. RAID-Z2 needs at least three disks per vdev, RAID-Z3 needs at least four, and a custom per-disk reserve must stay smaller than the disk size.
Review Capacity Ledger first, then compare Same-disk Comparison, Raw Capacity Allocation, Layout Yield Comparison, and Target Fit Paths when those tradeoffs matter. Use Capacity Assumptions before sharing a result so the units and reserve choices are visible.

Interpreting Results:

Planned max used is the primary planning output. It is the modeled capacity left for datasets, quotas, snapshots, and growth after per-disk reserve, mirror or parity overhead, RAID-Z padding, system slop, and operating reserve. Raw installed capacity is useful for purchase counting, but it is not the number to use as a fill target.

Status badges are warning signals, not guarantees. Balanced planning envelope means the selected inputs did not trigger a high-signal width, reserve, or padding warning. Needs topology review or Review workload fit means the capacity number may still be mathematically valid, but the layout or headroom choice deserves closer review before buying drives or setting quotas.

Capacity Ledger: shows where raw disk capacity went, including per-disk reserve, protection overhead, padding loss, slop, reserve, and planned max used.
Same-disk Comparison: compares Mirror, RAID-Z1, RAID-Z2, and RAID-Z3 using the same disk count, disk size, recordsize, ashift, slop, and reserve assumptions.
Raw Capacity Allocation: separates planned max used from reserves and overhead so the dominant deduction is visible.
Target Fit Paths: shows whether the current layout already clears the target or needs a layout change, more vdevs, or larger disks.
Layout Briefing: summarizes topology, fault tolerance, performance bias, expansion increment, and any special-vdev caution.

Technical Details:

ZFS pools are built from top-level vdevs. The pool stripes allocations across those vdevs, and each vdev supplies its own redundancy behavior. Mirrors replicate each block across members. RAID-Z uses distributed parity, so the data capacity depends on parity count, vdev width, sector size, and how a record is split into sectors.

The model is an estimate of a planning envelope, not a live filesystem accounting report. It uses equal-size disks, applies any per-disk reserve before layout math, estimates RAID-Z padding from recordsize and ashift, subtracts slop, and then holds back the selected operating reserve. It does not model compression gain, deduplication cost, snapshot retention, metadata expansion, fragmentation history, or mixed-size replacement behavior.

Formula Core:

The final planned capacity is calculated from padding-aware capacity, slop, and operating reserve.

P_{planned} = \max (A - S, 0) \times (1 - \frac{R_{op}}{100})

Pplanned is Planned max used, A is padding-aware available capacity before slop, S is system slop reservation, and Rop is the operating reserve percentage.

A = (B_{disk} - B_{reserve}) \times W \times V \times r

Bdisk is one disk's entered capacity, Breserve is per-disk reserve, W is disks per vdev, V is vdev count, and r is the layout ratio. For mirrors, r = 1 / W. For RAID-Z, r is a padding-aware ratio based on records, sectors, and parity.

r_{raidz} = \frac{N_{data-sectors}}{⌈ \frac{N_{data-sectors} + N_{stripes} \times P}{P + 1} ⌉ \times (P + 1)}

For RAID-Z, data sectors come from recordsize divided by sector size, stripes are the number of data-stripe groups needed for the record, and P is the parity count. The displayed model rounds the ratio down to a 1/512 step before multiplying it by member raw capacity.

S_{auto} = clamp (\frac{A}{32}, 128 MiB, 128 GiB)

Manual slop uses the selected percent of padding-aware available capacity, and off mode sets slop to zero. OpenZFS auto slop follows the 1/32 planning rule with the lower and upper bounds shown above.

ZFS capacity inputs and effects
Input	Role in the model	Main output affected
Vdev layout	Sets mirror behavior or RAID-Z parity count.	Protection overhead, fault cushion, planned max used.
Disks per vdev	Controls mirror width or RAID-Z data/parity width.	Usable disks per vdev, padding loss, and expansion increment.
Vdev count	Multiplies the top-level vdev capacity and disk inventory.	Raw installed capacity and same-layout expansion paths.
Recordsize and sector size	Drive the RAID-Z partial-stripe padding estimate.	RAID-Z padding loss and padding-aware available capacity.
Slop handling	Holds back OpenZFS-style system capacity before user reserve.	System slop reservation and planned max used.
Operating reserve	Holds back a selected percent after slop.	Planned max used, raw yield, and workload-fit warnings.
Target planned max used	Compares current capacity with same-disk alternatives, added vdevs, and larger disks.	Target Fit Paths and Layout Yield Comparison markers.

ZFS result boundary guide
Signal	Condition	Meaning
Needs topology review	RAID-Z1 with 8 or more disks per vdev.	Capacity may look attractive, but the single-parity rebuild exposure deserves review.
Review workload fit	RAID-Z padding loss at 12% or more, mirror width above 2, or operating reserve below 10%.	The number can still be usable, but the assumptions should be checked against workload and risk tolerance.
Balanced planning envelope	No major width, padding, or reserve warning is triggered.	The selected inputs did not trip a high-signal capacity warning in this model.

Accuracy Notes:

The calculation is deterministic for the inputs shown, but a live ZFS pool can report different numbers. Dataset compression, deduplication, snapshot retention, metadata growth, allocation history, replacement timing, and mixed-size members can all shift real-world usable space away from a clean planning estimate.

All modeled data vdevs use equal-size members.
Per-disk reserve is subtracted before mirror or RAID-Z overhead.
The comparison table keeps disk count, disk size, recordsize, ashift, slop, and reserve assumptions fixed while changing layout family.
Special vdev input is a namespace planning estimate, not a full fast-media sizing model or reliability plan.
The result does not measure resilver duration, drive reliability, performance, fragmentation, or pool health.

Advanced Tips:

Use decimal TB for vendor drive labels and binary TiB when matching an operating-system report. The paired display helps, but starting with the same unit as the source avoids a false shortfall.
Keep Recordsize assumption, Sector size assumption, Slop handling, and Operating reserve fixed while comparing layouts. The Same-disk Comparison table is only meaningful when those assumptions stay aligned.
Lower Recordsize assumption only when the workload really writes smaller blocks. On RAID-Z, small records can raise RAID-Z padding loss and make a wide vdev look less efficient than a simple parity count suggests.
Use Target planned max used for purchase planning instead of mental math. Target Fit Paths separates same-disk layout changes, added vdevs, and larger-disk refreshes so capacity gains do not hide a lower fault cushion.
Model platform-specific disk reservations with Per-disk reserve profile before comparing pool shapes. A small per-disk carveout can matter across many drives, especially when a target is close.
Treat Special vdev carveout as a namespace estimate only. It does not size mirrored fast media, metadata risk, small-block policies, or replacement strategy for the special vdev class.

Worked Examples:

A 2 x 12-disk RAID-Z2 plan with 14 TB drives, 128 KiB recordsize, 4 KiB sectors, OpenZFS auto slop, and 20% operating reserve starts from 336 TB of installed raw capacity. The RAID-Z padding model uses a 390/512 ratio for these assumptions, auto slop reaches the 128 GiB cap, and Planned max used lands near 186.12 TiB with the default TiB output unit.

An 8-disk RAID-Z2 vdev using 18 TB drives and the same recordsize, sector, slop, and reserve settings reports about 74.39 TiB as Planned max used. If Target planned max used is set to 90 TiB, the target is short by roughly 15.61 TiB, and Target Fit Paths points to adding another 8-disk RAID-Z2 vdev or refreshing to larger disks under the same topology.

An 8-disk RAID-Z1 plan with 12 TB drives can show about 58.70 TiB planned max used, but the status becomes Needs topology review because the vdev has only one parity disk across a wide group. The capacity is not the problem by itself; the warning is about the smaller fault cushion and rebuild exposure.

A 4 x 2-disk mirror plan with 12 TB drives reports about 34.82 TiB planned max used. Changing each mirror vdev from two disks to three would improve the mirror copy cushion, but it would not add data capacity inside each mirror vdev. To increase capacity while keeping mirrors, add more mirror vdevs or larger drives.

If a custom per-disk reserve of 2 TiB is entered for 1 TB disks, the summary changes to Check inputs. Reduce the custom reserve, increase disk size, or return the reserve profile to No per-disk reserve before trusting the ledger or target analysis.

FAQ:

Why is planned max used lower than the raw disk total?

Raw capacity includes every byte on every entered disk. Planned max used subtracts per-disk reserve, mirror or parity overhead, RAID-Z padding, OpenZFS-style slop, and the operating reserve you selected.

Should I enter TB or TiB?

Use TB for drive label sizes because disk vendors usually use decimal units. Use TiB when you are matching an operating-system report or another tool that already reports binary units.

Why does recordsize change a capacity estimate?

RAID-Z writes records across data and parity sectors. Smaller records on wider parity vdevs can leave padding sectors, so the same raw disk set can produce a smaller padding-aware number.

Does a higher planned capacity mean the layout is better?

No. Same-disk Comparison may show more capacity for a layout with a smaller fault cushion. Check the status badge, fault budget, and Capacity signal before treating the capacity leader as the better design.

What should I fix when the result says Check inputs?

Reduce the per-disk reserve, increase disk size, or choose a valid vdev width for the selected layout. RAID-Z2 needs at least 3 disks per vdev, and RAID-Z3 needs at least 4.

Does the special vdev carveout reduce planned max used?

No. It estimates how much of the final namespace might live on special vdevs for metadata or small blocks. Special vdev devices still need separate mirrored fast-media planning.

Glossary:

Vdev: A top-level ZFS virtual device, such as a mirror or RAID-Z group, that contributes capacity and fault behavior to the pool.
RAID-Z padding: Extra sectors consumed when data and parity sectors do not fill a clean stripe under the selected recordsize and sector size.
Ashift: The vdev alignment shift; 2 to the ashift power is the smallest allocation unit used for the sector-size assumption.
Slop reservation: System capacity held back so ZFS avoids running completely out of allocatable space.
Operating reserve: User-selected headroom held unused after slop for allocator behavior, snapshots, and growth control.
Planned max used: The final capacity target after modeled layout, padding, slop, and reserve deductions.
Special vdev: A separate vdev class used for metadata and optionally small blocks; it is pool-critical and should be planned for redundancy.

References:

VDEVs, OpenZFS documentation.
RAIDZ, OpenZFS documentation.
Module Parameters: spa_slop_shift, OpenZFS documentation.
Workload Tuning, OpenZFS documentation.