ONTAP Capacity Planning & Forecasting Guide

The three numbers admins confuse

Example: 10 × 1.92 TB SSDs advertise 19.2 TB raw. If one remains spare and a nine-drive RAID-DP group uses two parity drives, seven drives contribute data before ONTAP/WAFL reservation: 13.44 TB decimal. A measured 2:1 efficiency would represent roughly twice the final usable capacity as effective capacity. Exact usable space differs with drive formatting, partitioning, RAID layout, platform, and ONTAP version; use the system’s displayed values.

cluster::> storage aggregate show -aggregate aggr1 -fields size,used,available,percent-used
aggregate size   used   available percent-used
aggr1     40.00TB 31.20TB 8.80TB  78%

Planning inputs

• Baseline and growth: at least several representative intervals, separated by workload.
• Retention: snapshot creation, deletion, change rate, replication, and backup staging.
• Protection: RAID parity, compatible spares, and rebuild headroom.
• Guarantees: thick commitments, thin volumes, LUN overwrite/fractional reserve behavior, and aggregate oversubscription.
• Metadata: file count and inode limits—especially for FlexGroup constituents—plus small-file workload effects.
• Events: migrations, fiscal peaks, full backups, new tenants, and efficiency changes.

WAFL reservation is not a timeless “about 10%” constant. Official documentation says local tiers below 30 TB reserve 10% for aggregate metadata and performance; beginning with ONTAP 9.12.1, tiers of 30 TB or more can gain 5% usable space, with availability dependent on platform and version. Read the live system rather than subtracting a blanket percentage.

cluster::> storage aggregate show-space -aggregate aggr1
Aggregate : aggr1
Feature                                      Used      Used%
Volume Footprints                          31.20TB       78%
Aggregate Metadata                         820.0GB        2%
Total Used                                 32.02TB       80%

Snapshot reserve and aggregate reserve are different layers. Fractional reserve protects overwrite needs for snapshot-backed, space-reserved objects; settings and defaults depend on volume/LUN configuration. See FlexVol space guarantees.

Measure and retain a trend

A point-in-time CLI output is evidence, not a forecast. Collect aggregate and volume physical usage on a fixed cadence and preserve timestamps. Client df -h reports the client-visible filesystem and can differ from ONTAP physical use because of snapshots, efficiencies, and guarantees.

cluster::> volume show -fields size,used,available,percent-used,snapshot-reserve
vserver volume size   used   available percent-used snapshot-reserve
svm1    db     20TB   15.6TB 4.4TB     78%          5%
svm1    home   10TB   6.1TB  3.9TB     61%          5%

app01$ df -h /mnt/db
Filesystem             Size  Used Avail Use% Mounted on
192.0.2.10:/db          20T   16T  4.0T  80% /mnt/db

For automation, trend ONTAP REST resources such as /api/storage/aggregates (not /api/v1/storage/aggregates) and volumes, storing counters in a time-series system. Schema fields and privileges vary by ONTAP version. Active IQ can add fleet and AutoSupport history; see AutoSupport, EMS, and Active IQ.

$ curl -sS -u monitor:REDACTED   'https://cluster.example/api/storage/aggregates?fields=name,space' | jq '.records[]'
{
  "name": "aggr1",
  "space": {"block_storage": {"size": 43980465111040, "used": 34304762786611}}
}

Forecasting that survives contact with reality

Linear baseline: fit physical used capacity against time. If usage rises from 24.0 to 30.0 TB over five months, the observed slope is 1.2 TB/month. With a 40 TB usable boundary, 80% is 32 TB: only 1.7 months from the latest point. Use multiple windows and report uncertainty.

Seasonality: compare year-over-year peaks, month-end jobs, and ingest campaigns; a straight line through a seasonal trough is unsafe. Workload mix: a new encrypted, pre-compressed, or unique-data stream may lower the dedupe/compression ratio. Forecast physical growth by workload, then sum it; do not multiply the whole estate by yesterday’s best ratio.

month,physical_used_tb
2026-03,25.2
2026-04,26.4
2026-05,27.6
2026-06,28.8
2026-07,30.0
# slope = (30.0 - 25.2) / 4 = 1.2 TB/month

The 80% planning line—and 100% reality

Use 80% as an internal planning trigger, not an ONTAP invariant. It leaves time and working space for snapshots, migrations, reconstruction, metadata growth, and forecast error. Choose a different threshold when measured workload volatility, platform guidance, or procurement lead time demands it.

Thin provisioning decouples promised volume size from physical capacity. Track sum of thin promises ÷ aggregate usable capacity and, more importantly, concurrent physical growth. There is no universal safe oversubscription ratio: 1.5:1 may be conservative for one estate and reckless for another. At physical exhaustion, affected writes can fail and volumes/LUNs may take protective actions according to their settings; do not wait for 100%.

cluster::> volume show -fields size,used,percent-used,space-guarantee
vserver volume size used  percent-used space-guarantee
svm1    db     20TB 18.8TB 94%          none
svm1    home   25TB 8.1TB  32%          none
cluster::> event log show -severity EMERGENCY,ALERT -time >1h
Time                Node  Severity Event
8/28/2026 10:14:02 node1 ALERT    wafl.vol.full: volume db is full

Put cold-tier consumption and retrieval behavior in the model for FabricPool. Capacity-based licensing can have separate licensed/managed capacity implications; reconcile the forecast with ONTAP licensing.

Worked example: 40 TB at 78%

An aggregate has 40 TB usable, 31.2 TB physically used (78%), and grows 1.2 TB/month. The team requires a 30% uncertainty buffer on projected growth, so planning growth is 1.56 TB/month.

Decision: order now. The planning line is about two weeks away. If procurement, installation, validation, and migration take eight weeks, capacity at delivery is roughly 34.32 TB (85.8%). Size the addition to cover the planning horizon plus headroom. For 12 more months after delivery: 12 × 1.56 = 18.72 TB buffered growth. Keeping the resulting system at or below 80% requires total usable capacity of (34.32 + 18.72) ÷ 0.8 = 66.3 TB—about 26.3 TB additional usable. Translate that usable target into supported drives, RAID groups, spares, shelves, and licenses with current NetApp sizing tools.

Pitfalls that break forecasts

• Applying a marketing efficiency ratio instead of measured physical change.
• Double-counting snapshot reserve as both unavailable capacity and forecast consumption.
• Ignoring WAFL/aggregate metadata and assuming one overhead percentage across versions and sizes.
• Forecasting from logical volume size while thin promises share one physical pool.
• Ignoring inode/file limits because bytes remain free.
• Building a small aggregate where fixed reservations and parity consume a disproportionate share.
• Treating NVRAM as capacity overhead: it protects pending writes, but it is not part of aggregate usable capacity.

Official sources

• Determine space usage in a local tier
• storage aggregate show and show-space
• volume show
• FlexGroup client and inode considerations
• ONTAP REST aggregates resource