ZFS Calculator: Estimate Usable Pool Capacity

A ZFS capacity calculator estimates a storage pool’s usable capacity from the number and size of its disks, the redundancy layout, and an allowance for reserved space. Enter the disk count, disk size, layout, and reserve percentage to see estimated usable capacity in decimal terabytes and tebibytes.

Formula

For a single-disk redundancy estimate, the simple formula is:

Usable capacity = disk count × disk size × (1 − redundancy fraction) × (1 − reserved fraction)

The calculator’s layout selector represents the number of disk-equivalents used for redundancy: one for a mirror or RAIDZ1, two for RAIDZ2, and three for RAIDZ3. Its effective formula is n × s × (1 − r/n) × (1 − u/100), where n is the number of disks, s is each disk’s stated capacity in decimal TB, r is the redundancy allowance in disk-equivalents, and u is the percentage reserved. This treats redundancy as a simple capacity subtraction; it is not a full ZFS allocation simulator.

The raw-capacity output is n × s. The TiB output converts the estimated decimal-terabyte result using 1 TiB = 1.099511627776 TB. The calculation assumes all disks are the same size and does not model ZFS metadata or allocation overhead.

Worked Example

Using the defaults—six 8 TB disks, RAIDZ2, and 20% reserved:

• Raw capacity: 6 × 8 = 48 TB.
• Two disk-equivalents are allowed for redundancy, leaving 6 − 2 = 4 disk-equivalents: 4 × 8 = 32 TB before the reserve.
• After reserving 20%: 32 × (1 − 0.20) = 25.60 TB estimated usable.
• Convert to tebibytes: 25.60 ÷ 1.099511627776 ≈ 23.28 TiB.

The calculator’s headline result is 25.60 TB. This is a planning estimate, not a promise that exactly that amount will appear as available space in a ZFS interface.

How ZFS Capacity Works

ZFS combines disks into virtual devices (vdevs), then combines one or more vdevs into a pool. Redundancy is established within each vdev. A pool can have multiple vdevs, and its overall reliability and capacity depend on how those vdevs are built; adding disks to a pool does not automatically create one larger fault-tolerant group.

Mirrors store copies of data across their member disks. A two-disk mirror therefore provides roughly one disk’s capacity, while a three-way mirror provides roughly one disk’s capacity as well. RAIDZ distributes data and parity across several disks. RAIDZ1, RAIDZ2, and RAIDZ3 use one, two, or three parity-equivalents per vdev, respectively. The calculator simplifies both mirror and RAIDZ layouts to a single redundancy allowance, so its mirror estimate does not account for extra copies in a three-way mirror.

For RAIDZ, the simple “disks minus parity disks” estimate is useful for rough planning, but actual capacity depends on vdev width, sector and allocation characteristics, and implementation details. Small RAIDZ vdevs can also have less efficient usable capacity than the simple formula suggests.

How to Choose Inputs

• Disk count: Count the drives in the vdev or group you are estimating, not every drive in a multi-vdev pool unless you calculate each group and add the results.
• Disk size: Use the manufacturer’s decimal TB rating consistently. If drives differ in size, a single-size estimate is unsuitable; ZFS generally limits a vdev’s capacity according to its smallest member.
• Layout: Choose the redundancy level actually used. A mirror’s number of copies and RAIDZ’s parity level affect the estimate differently in real configurations.
• Reserved space: This is a planning allowance, not a ZFS setting automatically applied by the calculator. Reserving space helps avoid planning to fill a pool completely.

A 1 TB drive is normally sold as 1,000,000,000,000 bytes, while operating systems may display capacity in TiB, where 1 TiB is 1,099,511,627,776 bytes. This is why a nominal 8 TB disk appears as about 7.28 TiB before formatting and filesystem overhead. TB and TiB are different units, not evidence that the disk has lost capacity.

Interpreting the Estimate and Its Limits

“Usable” can mean different things. Raw capacity is the sum of drive ratings. A redundancy-adjusted estimate removes space assigned to parity or copies. Available space is what a system reports as free for new data after pool structures, metadata, existing files, snapshots, reservations, and other allocations are considered. This calculator estimates the second quantity and applies a user-selected reserve; it does not predict the live free-space figure.

Do not plan to fill a ZFS pool to 100%. ZFS needs working room for allocation and can behave poorly when a pool is nearly full. Snapshots may retain old blocks after files are changed or deleted, so they can consume more space than expected. Compression may reduce physical storage used for suitable data, but its benefit depends on the contents and should not be counted as guaranteed capacity.

For a specific system, use the actual vdev topology and check the pool’s reported capacity and free space after creation. This estimate does not account for mixed disk sizes, sector padding, metadata, spare disks, deduplication, compression, snapshots, or special allocation classes.

Common Capacity Mistakes

• Subtracting parity but ignoring mirrors: A mirror stores copies; it is not equivalent to RAIDZ parity. A simple parity-style estimate can overstate capacity for multi-way mirrors.
• Mixing TB and TiB: Keep input and output units clear. The calculator reports decimal TB and a converted TiB estimate.
• Counting the whole pool as one vdev: For multiple vdevs, estimate each vdev according to its own width and layout, then combine estimates cautiously.
• Treating the result as free space: Reserved capacity, snapshots, metadata, and existing data affect what is actually available.

Frequently Asked Questions

How much usable space does six 8 TB disks in RAIDZ2 provide?
Using the simplified estimate, RAIDZ2 leaves four disk-equivalents after two parity-equivalents: 4 × 8 = 32 TB before any reserve. With a 20% reserve, the estimate is 25.60 TB, or about 23.28 TiB.

Why does ZFS show less space than the calculator?
The estimate is simplified. Displayed capacity may use TiB, and actual pool capacity also reflects layout details, metadata, allocation, reservations, snapshots, and data already stored.

Is a RAIDZ2 pool’s usable capacity always disks minus two?
No. That is a useful rough estimate for a uniform-width vdev, not an exact prediction for every configuration. Vdev width and allocation details affect the result.

Does a mirror use one disk for redundancy?
A two-way mirror has capacity roughly equal to one member disk. A mirror with more copies still stores duplicate data, so the simple one-disk redundancy setting does not accurately model it.

Should I include a spare disk in the disk count?
Only if it is an active member of the vdev. A spare set aside for replacement does not contribute ordinary pool capacity while it remains unused.

Related

• Access Claude Opus 4.6 Free? Plans and Options
• 100GB Free Cloud Storage? Real Options and Limits
• Best Free Photo Editors for PC: Which One to Choose

in n | Number of disks | - | 6 | 1
in s | Size per disk | TB | 8 | 0
sel r | Layout | Mirror=1, RAIDZ1=2, RAIDZ2=3, RAIDZ3=4
in u | Reserved space | % | 20 | 0
out usable | Estimated usable capacity | TB | n * s * (n - r) * 0 + n * s * (1 - r / n) * (1 - u / 100) | 2
out raw | Raw disk capacity | TB | n * s | 2
out teb | Estimated usable capacity | TiB | usable / 1.099511627776 | 2