Model the pool you intend to build
Start with the data vdevs. Add each mirror or RAIDZ group separately and enter its member capacities with the correct unit. The equal-drive control fills a group quickly; edit individual members when their sizes differ. Four drives arranged as two mirrors need two vdevs, because their failure boundaries differ from one four-drive mirror. Duplicate, reorder, or remove groups as you refine the plan.
Check the allocation assumptions before calculating:
| Input | What to choose |
|---|---|
| Workload and block size | Choose filesystem or zvol, then a representative recordsize or volblocksize. Compare scenarios if the real block mix is uncertain. |
ashift | Use the sector-alignment assumption for the planned pool. The default is an assumption to verify, not a tuning recommendation. |
| Slop shift | Model the OpenZFS reserve separately from the extra space you intend to leave free. |
| Planning headroom | Enter the extra percentage you don't intend to fill. It reduces the planning target, not estimated writable capacity. |
| Optional devices | Add spares, SLOG, L2ARC, or special vdevs only when they belong in the planned inventory. They do not increase the general data total. |
| Compression scenario | Enable it only to explore a stated ratio. Its logical-capacity estimate depends on achieving that ratio. |
Choose Calculate pool after editing the configuration. Estimated writable capacity is the physical-capacity answer under these assumptions. The planning target applies your headroom. An enabled compression scenario adds a separate hypothetical logical-capacity result; don't substitute it for physical capacity.
Use the allocation chart to see where entered data-device capacity goes, and the vdev table to inspect each group's contribution and failure boundary. Change the result unit to reformat the values without changing the model. Formula details identify the model and sources.
Copy the summary when you need the answer, or use Share configuration when you need someone else to inspect the inputs. Sharing puts the configuration in the URL. The generated dry-run command contains placeholders and is a review aid; verify the devices and command before using it on a real system. Reset returns to the starting configuration.
Each vdev is its own failure boundary
A vdev is a group of devices that ZFS uses as one building block of a pool. A pool can combine several top-level vdevs, but each 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 overview before 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 | Provides separate storage for the ZFS intent log used by synchronous writes | No |
| L2ARC | Caches reads | No |
| Special | Stores metadata and, when configured, small data blocks | Separate estimate, not ordinary data-vdev capacity |
A special vdev can hold data the pool needs permanently. It is not a disposable read cache; its protection needs deliberate planning. A spare, SLOG, or L2ARC device also must not be counted as another general data drive.
Why ashift and block size change RAIDZ capacity
ashift expresses the allocation sector size as a power of two. For example, ashift=12 means 4 KiB sectors. recordsize controls the maximum block size for ordinary filesystem data; volblocksize sets the block size of a zvol, which presents a block device. 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 reference describes 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.
The ZFS padding calculator explains one block's allocation in detail. For an existing RAIDZ vdev being widened, use the RAIDZ expansion planner rather than assuming it has fresh-pool efficiency.
Calculation stays in your browser. Choosing Share includes the entered configuration in its URL. The generated dry-run command is a review aid with placeholders, not permission to run a real pool-creation command against unverified devices.