Each vdev is its own failure boundary
A ZFS pool can combine several top-level vdevs, but each vdev keeps its own capacity and redundancy rules. A six-drive RAIDZ2 and a two-drive mirror should not be flattened into one generic disk group. The calculator models them separately, then adds their data contributions. Losing a complete top-level vdev can still lose the pool. Read the official OpenZFS vdev overviewbefore choosing a production topology.
| Layout | Minimum drives | Per-vdev tolerance |
|---|---|---|
| Mirror | 2 | Any members except the last copy |
| RAIDZ1 | 2 | 1 drive |
| RAIDZ2 | 3 | 2 drives |
| RAIDZ3 | 4 | 3 drives |
What the estimate includes
Every capacity is converted to exact bytes. The result shows mixed-size waste, mirror or parity cost, block allocation losses, OpenZFS slop, estimated writable capacity, and your separate planning target. Auxiliary devices remain inventory because they do not normally add general data capacity.
| Role | What it does | General data |
|---|---|---|
| Spare | Waits to replace a failed member | No |
| SLOG | Holds the separate intent log | No |
| L2ARC | Caches reads | No |
| Special | Stores selected block classes | Separate envelope |
Why ashift and block size change RAIDZ capacity
ashift sets the physical allocation sector size. recordsize applies to filesystems, while volblocksize applies to zvols. RAIDZ divides each selected logical block into sectors, adds parity, and rounds the allocation. Smaller blocks can therefore use a different proportion of the pool. The result models every block at the one size you select, not the varied block mix of a real workload. See the OpenZFS RAIDZ allocation guide.
Slop and planning headroom are different
Slop is capacity OpenZFS keeps unavailable for normal allocation so important operations can continue near a full pool. The default model uses a 1/32 shift with the documented floor and cap. Planning headroom is the extra percentage you choose not to fill. It changes the planning target, not estimated writable capacity. The OpenZFS module parameter referencedescribes the slop setting.
Why an installed pool can show less free space
This is a fresh-pool planning estimate, not a promise for zpool list,zfs list, TrueNAS, or another appliance. Partitioning, labels, metadata, fragmentation, snapshots, reservations, real block sizes, and allocation history can all change reported space. Previously expanded RAIDZ vdevs also keep historical allocation behavior. Use the generated zpool create -n command as a review aid only, then trust the values reported by the real pool after creation.