Get the inputs from the vdev you are widening
Use the values for one RAIDZ vdev, not totals for the whole pool. The exact output depends on the physical space already allocated and on the block geometry you choose to represent the workload.
| Input | What to use |
|---|---|
| Current physical allocation | Run zpool list -vp -o name,alloc and use the exact ALLOC value for the RAIDZ vdev you plan to widen. |
| Member sizes | Use the smallest existing member and the size of each planned added disk. Capacity above the smallest member stays outside this model. |
| Representative block size | Use recordsize for a filesystem or volblocksize for a zvol. Choose a size that represents the data you care about. |
ashift | Use the existing vdev's allocation sector shift. For example, ashift=12 means 4 KiB sectors. |
Why immediate capacity can be lower than a fresh vdev
RAIDZ expansion reflows allocated data across the wider device set, but it does not logically rewrite old blocks. Those blocks keep their original data-to-parity geometry, while blocks written after expansion use the wider geometry. A later rewrite can give data new block geometry, but OpenZFS warns that reported capacity can still remain pessimistic.
Current is the modeled envelope at the starting width. Immediate keeps old logical payload and uses the wider geometry for free physical space. Fresh models the whole final envelope at the final width. The geometry gap is the difference between fresh and immediate, not a prediction of zfs list or df.
Check the pool before you widen the vdev
The result is a capacity plan, not a safety decision. Verify the real pool and your platform before attaching a disk.
| Check | Why it matters | Source |
|---|---|---|
| Supported release | RAIDZ Expansion arrived in OpenZFS 2.3. Your platform may expose it later. | 2.3.0 release |
| Feature available | Confirm the org.openzfs:raidz_expansion feature is supported. | Feature reference |
| Healthy vdev | The target RAIDZ vdev must be healthy before expansion starts. | Attach reference |
| Current backup | Capacity math cannot verify your recovery path or hardware condition. | Operational check |
| Added disk size | The new disk must be at least as large as the smallest existing member. | Attach reference |
| Operation and parity | Each attach adds one disk. RAIDZ1, RAIDZ2, or RAIDZ3 does not change. | Layout guide |
What this model does not know
Version 1 assumes one current RAIDZ vdev that has never been expanded, followed by one-disk steps with no writes, deletes, or rewrites between them. It uses one representative block size. Real pools contain many block sizes, metadata, slop, fragmentation, compression, snapshots, and allocation history.
The planner does not inspect your system or predict live reporting, performance, duration, or failure risk. Calculation stays in this browser and does not store or send the inputs. Share deliberately puts the normalized configuration in the URL and copies that link. Use the ZFS pool capacity calculator for a fresh whole-pool plan, or check RAIDZ padding and block geometry for one allocation.