Why a Pool Reports Less Than the Sum of Its Drive Labels
You bought eight 4 TB drives, filled every bay, created the vdev, and the pool reports something in the low twenties. Nothing is broken and nothing is missing. Three separate deductions happened between the box on the shelf and the number your NAS prints, and only one of them is parity.
Drives are sold in decimal terabytes; ZFS, mdadm and most NAS dashboards report binary tebibytes. This converter handles that last step so you can plan a pool with the number the system will show you, not the number on the invoice.
Value in TiB = Value in TB ÷ 1.099511627776, that is × 0.909494701772928. So the eight-bay example: 8 × 4 TB = 32 TB of raw drives, which is 29.104 TiB before a single parity block is written.Where the Capacity Goes
Parity Comes Off the Top
Then the Unit Changes
The Pool Keeps a Reserve
And You Should Not Fill It
Planning a Pool Build Before You Buy the Drives
Do the parity arithmetic in decimal terabytes first, because that is the unit the drives are sold in. Only convert at the end, when you want to know what the dashboard will read.
Count the Data Drives
Subtract the parity drives from the bay count, then multiply by the label size. Eight bays of 4 TB in RAID-Z2 is (8 − 2) × 4 = 24 TB of data capacity.
Convert to What the Pool Will Report
Type 24 into the TB field. The TiB side updates as you type and shows 21.827 872 84 — close to what the pool status will read once overhead is counted.
Take Your Working Ceiling
Multiply the TiB result by 0.8 for the level you actually want to live at. For this build that is about 17.46 TiB of comfortable, everyday capacity.
Reverse It Into a Shopping List
Both fields accept input and the swap button flips the pair. Need 30 TiB of usable pool? Put 30 in the TiB side, read 32.985 TB, then work back through the parity level to a drive size and bay count.
Values pasted from a spec sheet convert as they are: a comma or a dot both work as the decimal mark, and stray spaces in the input are ignored.
Usable Pool Capacity by Bay Count and RAID Level
Each row takes a common home or small-office chassis, applies the parity cost of a single vdev, and converts the result to the tebibytes the pool will report. Figures are before slop space and metadata, so treat them as a ceiling rather than the free-space column.
Drive Count and Size to Pool Tebibytes
| Bays × drive | Raw (TB) | RAID-Z1 (TiB) | RAID-Z2 (TiB) | Mirrored pairs (TiB) |
|---|---|---|---|---|
| 4 × 4 TB | 16 TB | 10.914 TiB | 7.276 TiB | 7.276 TiB |
| 6 × 4 TB | 24 TB | 18.190 TiB | 14.552 TiB | 10.914 TiB |
| 8 × 4 TB | 32 TB | 25.466 TiB | 21.828 TiB | 14.552 TiB |
| 6 × 8 TB | 48 TB | 36.380 TiB | 29.104 TiB | 21.828 TiB |
| 8 × 12 TB | 96 TB | 76.398 TiB | 65.484 TiB | 43.656 TiB |
| 12 × 16 TB | 192 TB | 160.071 TiB | 145.519 TiB | 87.311 TiB |
Parity costs proportionally less as the vdev widens: RAID-Z2 on four bays gives up half the raw capacity, on twelve only a sixth. That is the real argument for wider vdevs — and resilver risk, not capacity, is what should stop you widening them further.
Bay-Count Arithmetic, Checked
See the tebibyte gap between RAID-Z1 and RAID-Z2 on the same chassis before you commit the vdev layout — a decision you cannot undo without destroying the pool.
Speaks the Dashboard's Unit
The pool status, zpool list and most NAS web interfaces count in binary units. Converting first means your build plan and your monitoring page finally agree.
Bare Numbers for the Build Sheet
The copy button on each field lifts the digits alone, no unit suffix attached, ready for a parts spreadsheet or a forum post asking for a second opinion.
Any Pair the Build Throws at You
Each side has a searchable unit list covering the whole storage family, so a dataset quoted in GiB or a drive spec in GB fits into the same two fields without opening another page.
NAS Pool Capacity Questions
Why does my eight-bay pool report far less than 8 × 4 TB?
Two deductions stack. RAID-Z2 gives two drives' worth of space to parity, so 32 TB of drives becomes 24 TB of data capacity, and that 24 TB is reported as 21.828 TiB. Subtract the slop reserve and metadata and you land a little under 21.2 TiB — parity plus a change of counting base, not a defect.
What is the slop space ZFS holds back, and can I reclaim it?
It is a reserve ZFS refuses to hand to normal writes, so a pool sitting at 100 percent can still complete the transactions that free space — deleting a file is itself a write. The default is one thirty-second, about 3.125 percent, tunable via spa_slop_shift; on 21.828 TiB that is roughly 0.68 TiB. Plan around it rather than tune it away.
Is the 80 percent guidance still worth following?
As a planning number, yes. Copy-on-write needs usable free space to place blocks efficiently, and the allocator slows as the pool fills. Newer OpenZFS releases cope better than the versions the rule was coined for, and many people run to 90 percent on a lightly-written media library. Size for 80 percent, alert at 90 — about 17.46 TiB of content on the eight-bay build.
What happens if I put a 12 TB drive into a vdev of 8 TB drives?
The vdev treats every member as the smallest, so a 12 TB drive contributes 8 TB and the rest sits idle: five 8 TB drives plus one 12 TB still behave as 6 × 8 TB. Replace the smaller members one at a time, letting each resilver finish, and the vdev expands once the last one is out, provided autoexpand is on.
Can I grow the pool later without rebuilding it?
Three routes. Add a second vdev of the same layout — works on any version, but you buy several drives and pay for parity again. Replace every drive in a vdev with a larger model, one at a time with a resilver between each. Or, since OpenZFS 2.3, expand a RAID-Z vdev by a single disk, though blocks written earlier keep their old parity ratio until rewritten. The parity level itself is fixed at creation.
No comments yet. Be the first to comment!