ZFS RAIDZ Pool Capacity Calculator – Usable Space & TiB

A ZFS-specific capacity calculator that models a real pool of one or more vdevs — RAIDZ1, RAIDZ2, RAIDZ3, mirror, or stripe — not just a single array. See raw capacity, parity loss per vdev, usable space before and after the ~3.2% ZFS slop reservation, storage efficiency, and how many drive failures the pool survives. Results show both vendor TB and the TiB your system actually reports. Everything runs locally in your browser.

🔒 Pure browser calculation — nothing is uploaded.

Pool capacity

Total disks in pool—
Data disks (usable)—
Parity disks (lost to redundancy)—
Raw capacity—
Usable (parity removed)—
Usable after ~3.2% ZFS reservation—
Effective capacity with compression—
Storage efficiency—
Drive failures tolerated (per vdev)—

Usable figures are an estimate. RAIDZ block padding (worse at small recordsize/volblocksize) can reduce real usable space further. "Effective capacity with compression" is the after-reservation usable space multiplied by your chosen ratio — it's how much logical data fits once ZFS compresses it, and only applies to compressible data. See the FAQ.

Planning a ZFS pool's capacity

A ZFS pool is built from one or more vdevs, and the pool's usable space is the sum of what each vdev contributes after parity. Because ZFS stripes data across vdevs, two 6-disk RAIDZ2 vdevs give you more usable space and faster performance than one 12-disk RAIDZ2 vdev — at the cost of four parity disks instead of two. This calculator models that vdev-by-vdev reality, which a single-array RAID calculator can't.

The number that surprises people is the gap between the parity math and what zpool list actually reports as free. ZFS withholds a slop reservation so its copy-on-write engine never wedges at 100% full, drives are measured in decimal TB but reported in binary TiB, and RAIDZ adds padding per block that grows as your recordsize shrinks. The figures here fold in the reservation and the TB→TiB conversion and flag the padding caveat, so your real-world free space lands close to the "after reservation" row rather than the raw total.

Compression can change the picture, but by realistic amounts. With lz4 on by default, ZFS shrinks compressible data before writing it. Commonly reported compressratios land around 1.02× for already-compressed media, ~1.2× for VM images and databases, ~1.45× across a mixed pool, and ~2.45× for text, JSON, CSV, and backups; only highly repetitive log files reach the ~10× range. Set the ratio above to apply the figure that matches your data — and keep a media-heavy pool at 1.0×, since photos, video, and archives won't shrink no matter the algorithm.

Need plain RAID 5/6/10 or hardware-controller levels instead of ZFS? Use the broader RAID calculator, which covers every common RAID level and their performance trade-offs.

Frequently Asked Questions

For each vdev, usable data disks = total disks minus parity disks (1 for RAIDZ1, 2 for RAIDZ2, 3 for RAIDZ3). Multiply the data disks by the drive size, then by the number of identical vdevs in the pool. This calculator sums that across vdevs and then subtracts the ZFS slop reservation to estimate what you can actually write.

Three reasons stack up: ZFS reserves roughly 3.2% of the pool as slop space it won't let you fill, RAIDZ adds per-block parity padding that grows with smaller recordsize/volblocksize (especially harsh for zvols at the default 8K–16K), and drives are sold in decimal TB while the system reports binary TiB. This tool models the reservation and the TB/TiB gap; padding loss depends on your workload, so treat the figure as a close upper estimate.

OpenZFS holds back a small portion of every pool (about 1/32, ~3.2%, with a cap on very large pools) so the copy-on-write filesystem can still free blocks and stay healthy when nearly full. You can't use that space, so this calculator shows usable capacity after subtracting it.

You lose the size of the parity disks per vdev: one disk for RAIDZ1, two for RAIDZ2, three for RAIDZ3. In a 6-disk vdev that's 17%, 33%, and 50% overhead respectively. Wider vdevs lose a smaller percentage but rebuild slower and riskier, which is why RAIDZ2 on 6–10 disks is the common sweet spot.

You can, and ZFS will stripe across them, but this calculator assumes identical vdevs because that's the recommended layout. Mismatched vdevs unbalance writes and the smallest disk in each RAIDZ vdev caps that vdev's per-disk size. For mixed layouts, calculate each vdev group separately and add the usable figures.

Manufacturers count 1 TB as 1,000,000,000,000 bytes (decimal), while ZFS and most tools report TiB using 1,099,511,627,776 bytes (binary). A 4 TB drive is about 3.64 TiB before any parity or reservation. This calculator shows both so the smaller on-screen number isn't a surprise.

Each vdev tolerates its parity count — RAIDZ2 survives any two failures within that vdev. But the pool fails if any single vdev loses more disks than its parity, so adding vdevs increases capacity and the total disks at risk, not the per-vdev tolerance. Mirrors survive all-but-one disk per vdev.

It calculates a fixed layout. OpenZFS now supports adding a disk to an existing RAIDZ vdev, but already-written data keeps its old parity ratio until rewritten, so post-expansion usable space can differ from a freshly built vdev of the new width. Recalculate after a full rewrite for the steady-state figure.

ZFS compresses data inline (lz4 is on by default, zstd is stronger), so compressible content stores in less physical space and your effective capacity grows. The multiplier is the dataset's compressratio. Typical reported figures: already-compressed media ≈1.02×, VM images and databases ≈1.17–1.19×, a mixed general-purpose pool ≈1.45×, and text/JSON/CSV/backups ≈2.45×; repetitive log files compress hardest and can reach about 10×. Pick a ratio above and the calculator multiplies the after-reservation usable space by it. Crucially, compression never adds parity or reduces the reservation — it only lets more logical data fit in the same physical pool.

Already-compressed data — JPEG/PNG photos, H.264/H.265 video, MP3/FLAC audio, ZIP/gz archives, most encrypted blobs — is near-random to the compressor, so it stays at roughly 1.0× no matter the algorithm. Compression pays off for text, logs, databases, VM images, and source code. If your pool is mostly media, leave the ratio at 1.0× to avoid over-estimating; ZFS will still try lz4 cheaply and simply store incompressible blocks as-is.

No. The calculator is pure client-side JavaScript — nothing is uploaded, logged, or stored. It works offline once the page has loaded.