ZFS Capacity Calculator

Vdev layout:

Choose the top-level vdev shape for this pool estimate.

Disks per vdev:

Enter the width of each equivalent top-level vdev.

Vdev count:

Set how many matching vdevs are striped in the pool.

Disk size:

Enter the marketed capacity for one disk and select its unit.

Slop handling:

Choose how reserved ZFS slop space is removed before operating headroom.

Manual slop:

Override slop as a percent of the padding-aware capacity.

Recordsize assumption:

Pick the dataset block size used for the RAID-Z padding estimate.

Sector size assumption:

Match the physical or reported sector size used by ZFS allocation math.

Operating reserve:

Hold back extra free space after ZFS slop for normal operation.

Primary output unit:

Choose the leading unit for summary, ledger, and exports.

Target planned max used:

Leave at 0 to keep target-fit planning off.

Per-disk reserve profile:

Subtract platform swap, labels, or fixed reserve from every disk.

Custom per-disk reserve:

Set the fixed capacity removed from each disk before layout math.

Special vdev carveout:

Optional namespace share expected on special vdevs for metadata or small blocks.

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 }}

Export to PDF Fullscreen

Include query parameters

Embed:

Customize embed code

Include query parameters

Wrap embed in collapsible toggle

Collapse panel by default

Hide card frame (bare iframe)

Loading behavior

Width

Height

Aspect ratio (width : height)

Max height (optional)

Collapsible heading

Collapsible description (optional)

Allow fullscreen

Referrer policy

Sandbox tokens

ZFS capacity depends on vdev topology, not just the total number of disks. A pool stripes data across top-level vdevs, and each vdev has its own redundancy rule. Mirrors, RAID-Z1, RAID-Z2, and RAID-Z3 can all use the same disk inventory while producing very different usable capacity and failure behavior.

ZFS also reserves space for system operation and can lose capacity to RAID-Z padding, especially with small records on wide parity vdevs. A capacity estimate that ignores recordsize, sector size, slop reservation, and operating headroom can overstate what should be assigned to datasets.

The safest planning number is planned max used capacity: the capacity after layout overhead, padding, slop, and the chosen operating reserve.

Technical Details

Each selected layout first computes usable disks per vdev. A two-way mirror stores one disk worth of data per vdev. RAID-Z layouts subtract one, two, or three parity disks per vdev. The calculator then multiplies by vdev count and adjusts for per-disk reserve profiles.

RAID-Z padding is modeled from recordsize and ashift. Smaller records can waste more sectors in partial stripes. The calculator then subtracts a slop reservation, using the OpenZFS-style automatic model with minimum and maximum bounds, unless a manual percentage is selected.

Technical rule summary
Raw installed capacity	disk size x disks per vdev x vdev count
Layout capacity	member disk bytes x usable disks per vdev x vdev count
RAID-Z padding-aware capacity	layout capacity adjusted by recordsize and ashift model
Planned max used	padding-aware capacity minus slop and operating reserve
Special vdev estimate	optional percentage carveout from final namespace

Special vdev capacity is treated as a namespace planning signal only. In real ZFS pools, special allocation vdevs are pool-critical and should be redundant. This page does not model dedup tables, compression, mixed disk sizes, metadata growth, or workload-specific fragmentation.

Everyday Use & Decision Guide

Start with the intended topology: layout, disks per vdev, vdev count, and per-disk size. Use the output unit that matches your purchasing or operating document, then set an operating reserve that reflects how close you are willing to run the pool.

Use ZFS Capacity Ledger to see raw, member, parity, padding, slop, reserve, and planned max used rows.
Use Same-Disk Comparison before changing from RAID-Z2 to mirrors or RAID-Z3.
Use Target Fit Paths after entering a target planned max used capacity.
Use Market Disk Refresh when deciding whether larger disks are cleaner than adding vdevs.
Review warnings for wide RAID-Z1, wide RAID-Z2, small recordsize padding, low reserve, or special vdev assumptions.

Do not treat planned max used as a promise that the pool can run comfortably at every workload mix. Compression, snapshots, block size, metadata, and write pattern can move real-world results.

Step-by-Step Guide

Select mirror, RAID-Z1, RAID-Z2, or RAID-Z3.
Enter disks per vdev, vdev count, disk size, and output unit.
Set disk reserve profile, slop mode, operating reserve, recordsize, ashift, and optional special vdev percentage.
Add a target planned max used value if you want fit-path guidance.
Export the ledger, assumptions, comparison, target paths, refresh table, or JSON for review.

Interpreting Results

Planned max used capacity is the headline number because it reflects operational headroom after ZFS deductions. Raw installed capacity is useful for procurement but should not be assigned to datasets.

RAID-Z padding loss grows when the current recordsize and ashift combination does not pack neatly into parity stripes. If the warning says padding is material, compare a different vdev width or recordsize before buying hardware.

Fault tolerance is per vdev. A RAID-Z2 vdev tolerates two disk failures inside that vdev, but the pool is lost if any top-level vdev is lost.

Worked Examples

Backup pool. Twelve 18 TB disks as one RAID-Z2 vdev gives strong capacity yield, but the warning may ask for rebuild-window review. The ledger shows two parity disks per vdev, padding assumptions, slop, and operating reserve.

Virtual-machine pool. Four two-disk mirror vdevs cost more capacity, but the comparison table shows why mirror layouts often suit random I/O and flexible expansion better than one wide RAID-Z group.

Small-block concern. A RAID-Z2 layout with small recordsize and high ashift can show material padding loss. Use Same-Disk Comparison to check whether narrower vdevs or mirrors improve the planned number.

FAQ

Why does ZFS show less space than simple parity math?

The calculator includes per-disk reserve, RAID-Z padding, slop reservation, and operating reserve. Simple parity math only covers one part of the loss.

Does the estimate include compression or deduplication?

No. It assumes stored bytes are real bytes. Compression can improve effective capacity, while deduplication can add memory and metadata pressure.

What does ashift change?

Ashift represents the sector size used by ZFS. Larger sectors can increase padding effects for small records, especially on RAID-Z layouts.

Can I size a special vdev from this alone?

No. The special-vdev percentage is only a namespace estimate. Real special vdev sizing needs metadata and small-block analysis, and the vdev must be redundant.

Glossary

Vdev: A top-level ZFS virtual device such as a mirror or RAID-Z group.
Recordsize: The target data block size used for many ZFS dataset writes.
Ashift: The power-of-two sector size ZFS uses for allocation math.
Slop reservation: Space held back so the pool does not run to a dangerous full state.

References

OpenZFS zpool manual, OpenZFS documentation.
OpenZFS Workload Tuning, OpenZFS documentation.
NIST binary prefixes, NIST.