Home / Reference / Aggregate capacity math
Why is my usable capacity less than raw? The aggregate math
Every new ONTAP admin asks this after the first install: the shelf says 112 TiB raw, ONTAP says ~85 TiB usable, and the volumes show even less. This is not a bug — it's parity, reserves, spares, and the filesystem's own overhead. Here's the full breakdown, with a worked example you can reproduce.
The five things that eat raw capacity
| # | Factor | What it does | Typical magnitude |
|---|---|---|---|
| 1 | Drive capacity rounding | A "7 TiB" disk is 7 TiB binary, but drive vendors and ONTAP display conventions differ; ONTAP reports in TiB/GiB | small |
| 2 | RAID parity | RAID-DP = 2 parity drives per RAID group; RAID-TEC = 3 | ~13% (DP on 16+2), ~17% (TEC on 14+3) |
| 3 | Spares | Hot spares (typically 1–2 per shelf/HA pair, plus the two spare partitions on a 2-node split) | 1–2 drives + |
| 4 | WAFL reserve (aggregate reserve) | ONTAP reserves ~5–10% of the aggregate (traditionally 10%, often set lower) for WAFL internal operations; it shows as "aggregate reserve" space | 5–10% |
| 5 | Snapshot reserve + volume overhead | Each volume's snapshot reserve (default 5%) is held back from user data; the volume's own metadata/FlexVol overhead also counts | 5%+ per volume |
On top of these, a 2-node cluster splits the disk pool: disks are divided between the two nodes (one aggregate per node), each with its own spares, so you can't pool everything into one giant RAID group.
The worked example: 16 × 7 TiB in a 2-node cluster
Take 16 disks of 7 TiB each in one shelf, shared by two nodes. ONTAP will auto-provision one aggregate per node with the disks split (typically 7+7 data with 1+1 spare partitions, or 8 per node with 2 spares). Here's the math for one realistic layout:
Raw: 16 × 7 TiB = 112 TiB
Per node (8 disks each):
Spares: 1 disk (7 TiB) → 7 data disks per node
RAID-DP group: 7 disks (5 data + 2 parity)
Data per node: 5 × 7 TiB = 35 TiB
Two nodes: 70 TiB aggregate data
WAFL reserve ~10%: 70 × 0.90 = 63 TiB usable aggregate space
Snapshot reserve: (varies per volume, default 5%)
So 112 TiB raw lands around 63 TiB of aggregate space and ~60 TiB of user-visible volume space with default reserves — and that's before dedupe/compression, which work in your favor (see the storage efficiency guide).
Wait, my system says something different. Modern ONTAP auto-provisions with aggr auto-provision and often uses partitioned disks (one physical disk split into a root partition + data partition), so the exact split and spare count depend on release and config. The lesson is the sequence: parity → spares → reserve. Run the commands below on your own system to see the real numbers.
Where to see each number on your cluster
# Raw vs usable aggregate space (includes WAFL reserve)
storage aggregate show -fields aggregate,size,usable-size
# Which disks are spares vs data, and partition ownership
storage disk show -fields disk,type,usable-size,container-type
storage disk show -partition-ownership
# RAID layout of an aggregate (group size, parity type, disk count)
storage aggregate show-status
# How much of the aggregate is reserved/used
storage aggregate show -instance | grep -iE "size|usable|reserve"
# Volume-level: snapshot reserve and total size
volume show -fields volume,size,used,percent-snapshot-space
storage aggregate show -fields size,usable-size is the single best command: it shows the difference between the RAID-protected size and the usable size after the WAFL reserve in one line.
RAID-DP vs RAID-TEC vs RAID4
| RAID type | Parity per group | Disk failures tolerated | When ONTAP uses it |
|---|---|---|---|
| RAID4 | 1 | 1 | Legacy/small groups; rarely default today |
| RAID-DP | 2 | 2 | Default for most aggregates (group size typically up to 16–24 data disks) |
| RAID-TEC | 3 | 3 | Large HDD groups (e.g. 28-disk shelves) where rebuild time is long; also used on high-capacity QLC pools |
Larger RAID groups waste proportionally less on parity (16+2 is ~11% overhead vs 8+2 is 20%), but a bigger group takes longer to rebuild after a drive failure. ONTAP's defaults balance this; you can set the RAID group size per aggregate with storage aggregate create -raidtype raid_dp -diskcount N.
ASA and the single-pool note
ASA (SAN-only) systems differ: they present one big storage pool across the cluster rather than per-node aggregates in the same way, which simplifies the math — but parity and spares still apply. On any system, if you see "aggregate full" messages or volume space warnings, review the volume space troubleshooting guide before adding capacity.
Quick rules of thumb
- RAID-DP on a 2-node cluster: expect roughly 55–65% of raw as usable aggregate space (parity + spares + WAFL reserve).
- RAID-TEC on large HDD shelves: expect a bit less (~50–60%) because of the third parity.
- All-flash systems with small RAID groups: often ~65–75% because spares are a smaller fraction of a big flash pool and the aggregate reserve can be set to 5%.
- Volumes then lose another ~5% to snapshot reserve by default — budget it when sizing (sizing calculator).
Numbers vary by ONTAP release, drive size, and auto-provisioning decisions — always confirm with storage aggregate show -fields size,usable-size on your actual system before quoting a capacity number to anyone.