ZFS Capacity Calculator

A shelf of drives does not become usable ZFS space one-for-one. Capacity is first shaped by the top-level vdevs in the pool, then reduced by mirror copies or RAID-Z parity, sector padding, ZFS emergency slop space, and whatever operating headroom the administrator chooses to reserve.

The vdev is the important planning unit. ZFS distributes allocations across top-level vdevs, while redundancy lives inside each one. Losing more members than a single vdev can tolerate can therefore lose the pool even when plenty of other disks are healthy. Capacity and fault tolerance must be evaluated together, not as separate purchase-list questions.

“Approximately” matters for RAID-Z. A logical record is divided into allocation sectors, and each partial stripe still needs parity and alignment. Small records, large sectors, and a wide vdev can consume more space than the simple width-minus-parity estimate suggests. The dataset's representative recordsize and the vdev's configured ashift are therefore part of a serious capacity estimate.

There are also two different kinds of unused space. OpenZFS keeps slop space for recovery and administrative work when a pool is nearly full. An operating reserve is additional headroom for allocator performance, snapshots, workload growth, and planning uncertainty. Treating either reserve as ordinary usable capacity creates a pool that looks large on paper but reaches its practical limit early.

Decimal and binary units are another common source of disagreement. Drive vendors normally label capacity in TB, where one TB is 10¹² bytes. ZFS and operating-system reports often use TiB, where one TiB is 2⁴⁰ bytes. Changing the display unit does not change the physical capacity, but copying a number without its unit can make a correct estimate look wrong.

A capacity model supports topology comparison, hardware budgeting, and quota planning. It does not predict compression, deduplication, fragmentation, snapshot retention, resilver time, device health, or workload performance. Those remain separate design and operational questions.

How to Use This Tool:

Describe one equal-disk topology first, then add only the workload and platform assumptions that apply to the planned pool.

1. Choose Vdev layout, enter Disks per vdev, and set Vdev count. RAID-Z2 needs at least three disks per vdev and RAID-Z3 needs at least four.
2. Enter Capacity per disk with the unit printed on the drive or used by the source inventory. Switching units converts the value without changing the physical size.
3. Select the representative Recordsize assumption and configured Sector size assumption. These affect RAID-Z padding; they do not change mirror capacity.
4. Keep Slop handling on OpenZFS auto for ordinary planning, then choose an Operating reserve that reflects growth and performance headroom. Manual or off modes are comparison cases, not a claim that the live pool no longer needs emergency space.
5. Open Advanced when the platform reserves space on every disk, a target capacity must be met, or a namespace share is being considered for special vdevs. A custom per-disk reserve must remain smaller than one disk.
6. Read Planned max used with the Capacity ledger. When a target is set, compare the same-layout vdev expansion and same-topology disk-refresh paths before changing the design.

Interpreting Results:

Planned max used is the modeled fill ceiling after the selected protection, padding, slop, and operating reserve. Raw yield expresses that amount as a percentage of the disks' installed raw bytes; it is useful for comparing layouts but says nothing by itself about workload performance.

• Use Capacity ledger to identify the largest deduction. Parity or mirror overhead, RAID-Z padding, and unused-space reserves solve different problems.
• Compare layouts only while disk count, disk size, recordsize, ashift, slop mode, and operating reserve remain fixed.
• A positive target gap means the current plan exceeds the target; a negative gap means it is short. A zero required-vdev or required-disk result means the target lies outside the modeled search bound.
• The special-vdev split is only an indicative namespace allocation. It does not size special-vdev redundancy, metadata demand, small-block traffic, or performance.

Technical Details:

The calculation works in bytes and converts to TB, TiB, or another selected unit only for presentation. A fixed platform reserve is subtracted from every equal member before vdev capacity is calculated. Installed raw capacity still uses the full labeled disk size, so the reserve remains visible as a separate deduction.

Formula Core:

For a mirror with n members per vdev and v vdevs, one adjusted member contributes data capacity to each vdev. For RAID-Z with p parity columns, the simple layout ceiling is adjusted member size multiplied by n − p data columns and the vdev count.

RAID-Z padding is estimated from one representative logical record. The record is converted to allocation sectors of size 2^ashift. Full data rows and a possible partial row each add parity sectors, and the total is rounded to a multiple of p + 1. The ratio of data sectors to allocated sectors is then applied to adjusted member raw capacity. Mirrors bypass this padding path.

After padding, automatic slop uses the OpenZFS 1/32 model with a 128 MiB minimum, a 128 GiB maximum, and a half-capacity ceiling. The operating reserve is applied to the amount remaining after slop.

Here C_pad is padding-aware capacity and r is the operating-reserve percentage. Manual slop replaces the automatic rule with the selected percentage; off mode sets modeled slop to zero.

Target-fit rules:

When a nonzero target is supplied, the same-layout expansion path chooses the smallest whole vdev count from the current count through 256 whose planned capacity is at least the target. The disk-refresh path keeps the topology fixed and searches for the smallest equal raw disk size that meets the same target. Display values are rounded for readability; comparisons use the underlying byte values.

Accuracy Notes:

This is an equal-disk planning estimate, not live zpool accounting. Keep these limits visible when the result informs a purchase or migration:

• Mixed-size members, partition alignment, labels, existing allocations, fragmentation, and device-reported usable sectors can make a live pool differ.
• The RAID-Z padding estimate uses one selected recordsize and ashift. Real datasets contain a distribution of block sizes, metadata, compression outcomes, and small blocks.
• The fault budget counts member failures within one vdev. It does not estimate correlated failures, resilver exposure, unrecoverable read errors, or backups.
• Compression and deduplication are deliberately excluded from planned physical capacity because their benefit depends on actual data.
• Keeping more than 10% of pool capacity unused is an OpenZFS performance recommendation distinct from emergency slop; the chosen operating reserve should reflect that and the workload's growth risk.

Worked Examples:

References:

• VDEVs, OpenZFS documentation.
• RAIDZ, OpenZFS documentation.
• Quotas, reservations, and slop space, OpenZFS documentation.
• Workload tuning guidance, OpenZFS documentation.