I earn commissions when you sign up or buy through the affiliate links on this page, at no extra cost to you.

RAIDZ Expansion Calculator

Current vdev RAIDZ level Drives now × Drive size TB Data on the pool TB What zfs list shows as used. This is the data that keeps the old parity ratio.

Expansion Drives to add × Same size as the existing drives. OpenZFS expands one disk at a time; this plans the end state.

Embed this calculator on your site (free)

Free to use. The snippet is the calculator plus a one-line credit link, which is all I ask in return. It follows your visitor's light or dark setting automatically; add ?theme=light or ?theme=dark to the URL to pin it to your site.

<iframe src="https://dalil-tech.com/embed/raidz-expansion-calculator" title="RAIDZ Expansion Calculator by Dalil Tech" width="100%" height="820" style="border:1px solid #d0d7de;border-radius:10px;max-width:760px" loading="lazy"></iframe>
<p style="font:14px/1.6 system-ui,sans-serif;max-width:760px">Free <a href="https://dalil-tech.com/raidz-expansion-calculator">RAIDZ Expansion Calculator</a> by <a href="https://dalil-tech.com">Dalil Tech</a>.</p>

OpenZFS 2.3 lets you add a drive to a RAIDZ vdev, but the capacity you get right away is less than the naive math promises. Existing data keeps its old data-to-parity ratio until it is rewritten. This calculator shows all three numbers: what you have now, what you get right after expanding, and what rewriting your old data reclaims.

Why expansion gives you less than (n - parity) x size

RAIDZ expansion reflows your existing blocks across the wider vdev, but it does not re-stripe them. A block written on a 4-wide RAIDZ1 used 3 data sectors per 1 parity sector, and after expansion to 5-wide it still does; only new writes use the better 4-to-1 ratio. So the day the expansion finishes, the pool reports less free space than a fresh 5-wide vdev would have, and the gap is exactly your old data carrying its old parity overhead.

The gap closes as old data gets rewritten. A zfs send to a new dataset and back, a rebalancing script, or simply rewriting files over time all re-stripe blocks at the new width. The "reclaimable by rewriting" figure above is what that work buys you. If the pool is nearly empty when you expand, there is almost nothing to reclaim and you land at the full new capacity immediately.

I run SHR-1 on a Synology, not ZFS, so my mixed-size expansion story is different (SHR reshapes automatically). For RAIDZ the numbers here follow the OpenZFS allocation math, the same padding and slop model as the main RAID calculator, and the community references it against: the RAIDZ explainer covers the base geometry.

RAIDZ expansion FAQ

Does RAIDZ expansion rewrite my data?

No. It reflows existing blocks across the new, wider set of disks so the vdev stays balanced, but each block keeps the data-to-parity ratio it was written with. Only data written or rewritten after the expansion uses the new width's ratio.

How do I reclaim the missing space after expanding?

Rewrite the old data. A zfs send/recv into a new dataset, a rebalancing script that copies files in place, or natural churn over time all work. The calculator's "reclaimable by rewriting" figure is the prize for doing it.

Can I add more than one drive at a time?

OpenZFS expands one disk per operation, but you can run expansions back to back. Enter the total drives you plan to add and the calculator shows the end state.

Can I change the RAIDZ parity level while expanding?

No. Expansion widens the vdev at the same parity level. RAIDZ1 stays RAIDZ1. Moving to RAIDZ2 still means rebuilding the pool and restoring from backup.