ZFS RAIDZ Capacity Calculator
Estimate usable ZFS pool space for mirrors and RAIDZ1/2/3, including RAIDZ padding, slop space and record size.
Result
| Disks | 6 x 16.00 TB = 87.31 TiB (96.00 TB) raw |
|---|---|
| Survives | 2 failed disks per vdev |
| zpool list SIZE | about 87.30 TiB (95.98 TB) (includes parity) |
| Slop space reserved | 117.34 GiB |
| Usable (zfs list AVAIL, empty pool) | about 58.02 TiB (63.79 TB) |
| Usable for 128K records | about 58.07 TiB (63.85 TB) (66.7% of each block is data) |
| Plan to fill (keep 20% free) | about 46.46 TiB (51.08 TB) |
| Space efficiency | 66.5% of raw |
Note: Estimate for uncompressed data on an empty pool. Excludes SLOG, L2ARC, special vdevs and hot spares (they add no capacity), compression, dedup, snapshots and dRAID. Disk sizes are decimal TB as sold; ZFS reports binary TiB (shown as "T").
Learn more
How it works
The estimate follows the OpenZFS source step by step:
- Each disk loses 4.5 MiB to ZFS labels and boot space, and each vdev is used in whole metaslabs, so a little space at the end is left over.
- A RAIDZ vdev with N disks and P parity holds about (N-P)/N of its space. Each block is split into sectors (2ashift bytes), one parity sector is added per row, and the total is padded up to a multiple of P+1 sectors. The OpenZFS RAIDZ page shows this with a worked example.
zfs listreports space assuming 128K blocks. Bigger records fit slightly more than it shows; small records (databases, VM zvols) fit less, which is the "Usable for ... records" row.- Recent OpenZFS versions set aside one metaslab per large vdev for the ZIL, and hold back slop space: 1/32 of the pool, capped at 128 GiB, so the pool never fills completely.
Mirrors store a full copy on each disk, so a 2-way mirror gives half the raw space whatever the record size.
Worked example
The default is one RAIDZ2 vdev of six 16 TB disks with ashift 12:
- Raw: 6 x 16 TB = 96 TB (87.31 TiB).
zpool listshows about 87.30 TiB because RAIDZ SIZE includes parity. - A 128K block is 32 data sectors plus 2 x 8 = 16 parity sectors = 48, already a multiple of 3, so 2/3 of the space holds data.
- Slop space: 1/32 of the pool is over the 128 GiB cap, and part of it overlaps the ZIL metaslab, leaving 117.34 GiB.
- Usable: about 58.02 TiB (63.79 TB). Keeping 20% free leaves about 46.46 TiB to plan with.
With an 8K recordsize the same pool stores only about 29.04 TiB: each 8K block is 2 data sectors and 2 parity sectors, padded to 6, so only a third is data.
How much space do I lose with RAIDZ2?
Two disks' worth per vdev, plus padding that depends on block size. Six disks in RAIDZ2 give about 66% of raw space for normal files.
Why does zpool list show more space than zfs list?
For RAIDZ, zpool list counts raw space including parity. zfs list shows space you can actually write, after parity, padding and slop.
Do SLOG, L2ARC or spares add capacity?
No. A SLOG only holds the sync-write log, L2ARC is a read cache and spares sit idle until a disk fails. None of them add usable space, so they are not inputs here.
What is slop space?
Space ZFS keeps back so the pool can still delete files and do admin work when full: 1/32 of the pool, at least 128 MiB and at most 128 GiB.
Mirrors or RAIDZ?
Mirrors give better random I/O and faster resilvers but half the space (or less). RAIDZ2 gives more space and survives any two failures per vdev. Many storage builds use RAIDZ2 for bulk data and mirrors for VMs or databases.