How to use this ZFS RAID calculator
Enter the disk count for a single RAIDZ vdev and the capacity of its smallest member. Choose the parity level, then compare the first two results before assigning any compression benefit. Repeat for each vdev in a proposed pool and add the estimates. Do not enter the pool's combined disk count as if separate vdevs shared a single parity allowance.
This tool compares capacity scenarios. It does not predict application speed, replacement time or a minimum RAM specification. Keep a note of the inputs alongside any hardware shortlist so a later change in disk count or parity is visible in the budget. The three-level parity guide explains the recovery tradeoffs behind that choice.
The RAIDZ capacity formula
OpenZFS documents an approximation of (N − P) × X, where N is disk count, P is parity count and X is the smallest member's capacity. RAIDZ1 uses one parity equivalent, RAIDZ2 two and RAIDZ3 three. Parity is distributed across the drives. A group needs at least P + 1 devices, although minimum geometry alone does not make a layout a good match for a workload. See OpenZFS pool concepts.
Treat the result as space after parity and before other overhead. For unequal drive sizes, using the smallest member avoids counting capacity that the simple RAIDZ layout cannot use. Capacity assigned to a spare or a separate cache device does not belong in the data-vdev disk count.
Worked example: eight 18 TB disks
Eight disks provide 144 TB of advertised raw capacity. In RAIDZ2, subtract two disk equivalents: (8 − 2) × 18 = 108 TB before other overhead. Applying this calculator's 80% budget gives 108 × 0.8 = 86.4 TB. The same inputs in RAIDZ1 give 126 TB before other overhead, while RAIDZ3 gives 90 TB.
These are arithmetic examples, not measured capacities. If you assume a 1.35 compression ratio, the RAIDZ2 planning budget corresponds to 86.4 × 1.35 = 116.64 TB of logical data. The physical budget remains 86.4 TB. Changing the ratio changes the scenario's logical-data estimate; it does not create additional physical storage or reduce the parity allowance.
Why TB and TiB differ
The input uses decimal TB: one TB is 1,000,000,000,000 bytes. A TiB is 1,099,511,627,776 bytes, or 2 to the power of 40. Divide TB by approximately 1.0995 to express the same bytes in TiB. Thus 108 TB is about 98.2 TiB, and 86.4 TB is about 78.6 TiB. This conversion changes the unit, not the amount of storage. Keep both figures with your plan when comparing a disk label with an operating system's capacity display.
Record size, ashift and padding
The simple formula cannot reproduce every block allocation. RAIDZ uses variable stripe widths, and parity plus padding depends on the size of the records being stored. Small records on a wide group can consume more space than the headline data-to-parity ratio suggests. The OpenZFS workload tuning guide explains why workload and record size belong in capacity planning.
Sector alignment also matters. An ashift of 12 corresponds to a 4 KiB minimum I/O size; that is not a percentage discount this calculator can apply uniformly. Select alignment for the underlying disks before creating the vdev. Changing the pool's ashift property later does not realign existing vdevs. OpenZFS pool properties documents this distinction.
Free-space headroom and slop reserve
The 20% margin here is an explicit planning assumption. It is useful for comparing layouts without budgeting every estimated byte for files. It is not a universal performance boundary: fragmentation, workload and allocation patterns matter. Once the pool exists, use its actual allocation and dataset availability when setting operating limits, and allow for growth between capacity reviews.
OpenZFS separately reserves slop space for internal operations. The zfs(4) parameter manual describes spa_slop_shift and the reserve's bounds. The tool does not subtract an additional fixed 3.2% or claim to model that implementation detail. A purchasing estimate and the free bytes reported by a running dataset therefore serve different purposes.
Compression and snapshots need separate assumptions
No compression algorithm guarantees a particular ratio for your files. Keep the input at 1.0 for a baseline, then use a representative dataset's compressratio property for a second scenario. Already compressed content may offer little further saving. The dataset properties manual defines compressratio and the compression setting.
Snapshots retain blocks that would otherwise be freed as data changes. A plan based only on today's live files can therefore understate future physical use. Allow separately for retention and churn; neither is an input to this calculator. Quotas and reservations can also make a dataset's available space differ from the pool-level estimate.
RAM and future expansion
Pool capacity does not determine ARC size. Use the ZFS RAM requirements guide to budget for the host's workload, and the ZFS ARC size guide for an existing installation. The OpenZFS ARC documentation describes a memory-derived default and when application pressure justifies a limit.
For expansion, model the proposed geometry as a separate scenario. Supported RAIDZ expansion widens a vdev without changing its parity level, and existing blocks retain their original data-to-parity ratio. The zpool attach manual explains why simply recalculating the new disk count cannot predict an expanded pool's exact availability. Keep recovery planning alongside capacity planning: reading a degraded pool is the next step when an existing array has lost a member.