ZFS and RAIDZ capacity calculator
How much of a pool you actually get to use, once parity, the TB-to-TiB conversion and the 80% fill line have taken their share.
The pool
What you get
- Usable capacity
- —TiB
- Recommended maximum fill (80%)
- —TiB
- Same figure in decimal TB
- —TB
- Raw capacity of all disks
- —TiB
- Kept after parity and unit conversion
- —%
- Disks in total, spares included
- —
- Disk failures survived, per vdev
- —
Why the number is lower than you expected
- Two of the losses happen before ZFS is involved. Disks are sold in decimal terabytes and reported by the OS in binary tebibytes, which costs about 9% on its own. Parity costs the rest.
- RAIDZ has allocation overhead this calculator does not model. Every block is padded to a multiple of the parity width, so small blocks pay proportionally more parity than large ones. Expect to land a few percent below the figure above — more with a wide vdev, a small recordsize, or a lot of small files.
- ZFS keeps roughly 1/32 of the pool to itself so that a full pool can still free space. You will never see the last of it.
- zpool list and zfs list will disagree on a RAIDZ pool. The first reports raw space including parity, the second reports what you can actually write. That is not a bug, and the second one is the number this calculator gives you.
- The 80% line is about speed, not safety. Past it the allocator works harder to find contiguous space and write performance falls away.
- A pool dies with any one of its vdevs. Two RAIDZ2 vdevs do not survive four failures — they survive two in each. Losing three disks in the same vdev takes the whole pool with it.
Everything on this page is worked out in your browser. Nothing you type is submitted, stored or logged, and the page makes no requests after it loads.