NetApp ONTAP Space Usage: Where Did the Aggregate Space Go?

Every NetApp administrator eventually asks the same question: "the disks are 1.8 TB, so why does my aggregate only show 1.6 TB?" The answer is a stack of normal ONTAP behaviors — right-sized disks, WAFL overhead, spares, and guarantees — that are easy to mistake for a problem. This article works through the most common ONTAP space-usage questions from the NetApp Knowledge Base: where space goes, why it never matches rated capacity, and what you can actually do to reclaim aggregate space.

It is worth starting with the mental model. An aggregate is a pool of physical RAID groups, and ONTAP publishes three different numbers for it: the raw capacity of the drives as shipped, the usable capacity after RAID and right-sizing, and the space that is actually free right now. Almost every "missing space" ticket is caused by comparing two of those three numbers as if they were the same one.

Why Aggregate Capacity Never Matches Rated Disk Size

Right-sizing: when you add a disk, Data ONTAP rounds the usable space down to maintain compatibility across manufacturers. sysconfig -r shows less than rated capacity per disk — this is normal, not a fault.

WAFL overhead reserve: 5–10% of total usable space is reserved for WAFL metadata. From ONTAP 9.12.1 the reserve for aggregates over 30 TB dropped from 10% to 5% on AFF and FAS500f platforms; from 9.14.1 the same reduction applies to all FAS platforms.

Spares: spare disks are not counted in total usable space at all. Run sysconfig -r to see how many spares exist.

The right-sizing adjustment is the least intuitive of the three. A drive marketed as 1.8 TB does not present 1.8 TB to WAFL, because ONTAP deliberately shaves the usable number down to a value that every supported drive of that class can agree on. That is why two shelves from different vendors, both full of "1.8 TB" drives, will report slightly different sizes — and why the difference is not a defect on either side.

RAID parity adds a second subtraction that depends entirely on your RAID group size. A RAID-DP group of 24 data disks plus two parity disks yields roughly 24/26 of the group capacity; a smaller group of 8 plus 2 yields roughly 8/10. The parity disks themselves appear in sysconfig -r as normal members of the RAID group, which is another reason the arithmetic never lands exactly where people expect.

A Worked Example: Where 1.8 TB Per Disk Actually Goes

The table below follows a single shelf of 1.8 TB SAS drives through the deductions, in the order ONTAP applies them. Numbers are illustrative, but the sequence and the approximate magnitudes are what you will see in a real storage aggregate show-space output.

Read the table top to bottom and the mystery largely disappears. Only the first two rows are fixed by physics and platform policy; everything below them is a knob you can tune, which is exactly what the reclamation section at the end of this article is about.

Flash Pool: Cache Disks Don't Add Space

If an aggregate is configured as a Flash Pool (hybrid_enabled on in aggr options), the SSD RAID group identified in aggr status -r or sysconfig -r does not increase usable space — those SSDs are cache only.

This is the single most common source of "we added SSDs and got no capacity" complaints. In a Flash Pool the SSDs extend the aggregate's cache, not its usable capacity, and they are held to the same RAID protection rules as the HDDs. Check the setting with aggr options <aggregate> and look for hybrid_enabled; if it is on, the SSD RAID group is doing its job by accelerating reads and absorbing writes, and the only way to grow capacity is to add HDDs or move volumes to a different aggregate.

Finding Where the Space Went: show-space and show-footprint

storage aggregate show-space -aggregate aggr1
df -A aggr1
volume show-footprint -volume vol1
volume show -vserver svm1 -fields size,used,available,percent-used,space-guarantee,snapshot-reserve

storage aggregate show-space is the authoritative breakdown of a single aggregate: it lists the aggregate reserve, snapshot reserve, snapshot spill, volume footprint and the genuinely free figure, so you can see at a glance whether the shortfall is metadata, snapshots or user data. df -A gives the same view in one line, which is handy when you are scanning several aggregates to find the one that is nearly full.

volume show-footprint answers the complementary question — how much of that aggregate each volume is actually occupying, including its metadata and its share of overhead. On a cluster where one volume has quietly grown, this is faster than adding up per-volume sizes by hand. Both commands are read-only and safe to run at any time.

Volume Guarantees and Overcommitment

volume show -fields space-guarantee
volume modify -vserver svm1 -volume vol1 -space-guarantee none

A volume-guaranteed volume reserves its full nominal size in the aggregate whether or not it is full. Ten 1 TB guaranteed volumes in a 10 TB aggregate leave nothing for anything else, even if every volume is empty. Changing the guarantee to none releases that reservation and shrinks the aggregate footprint dramatically — at the cost of relying on free space being available when writes arrive.

Overcommitment is the aggregate-level expression of the same idea: an aggregate whose committed size exceeds its physical size is overcommitted, and it works perfectly until the thin volumes all decide to grow at once. The trade-off is deliberate and legitimate, but it has to be a decision rather than an accident. Watch the aggregate's free space and set an EMS threshold you will actually notice, rather than discovering the limit during a backup window.

Snapshots, Snapshot Reserve and Snapshot Spill

volume snapshot show -vserver svm1 -volume vol1 -fields size
storage aggregate modify -aggregate aggr1 -fields percent-snapshot-space
volume snapshot autodelete show -vserver svm1 -volume vol1

Snapshot reserve is the slice of the aggregate set aside for snapshots; snapshot spill is what happens when snapshots exceed that reserve and start eating into free space. In storage aggregate show-space you will see them as separate lines for exactly this reason — a healthy aggregate may show a modest snapshot reserve and zero spill, while a struggling one shows spill climbing every night as a backup or a replication stream accumulates copies faster than the schedule deletes them.

Snapshot autodelete is the escape valve. Configured properly it removes the oldest snapshots, and if necessary the oldest Snapshot copies of specific policies, once a threshold is crossed. Left unconfigured it does nothing, and the aggregate fills. For any volume carrying a schedule denser than hourly, verify that autodelete is enabled before the volume reaches seventy percent.

Fractional Reserve and LUN Space

LUNs add one more layer that does not exist for pure NAS volumes. Fractional reserve protects overwrites to a LUN when the space those overwrites would consume cannot be proven to exist — and when it is enabled, ONTAP effectively holds back the full LUN size. Describing a LUN's space story properly means checking three things at once: the LUN's reported size, the volume's guarantee, and the overhead reserve for the snapshots that protect it. A thin-provisioned LUN in a none-guarantee volume behaves very differently from the same LUN in a guaranteed volume, and the difference shows up as aggregate "used" space with no user data to explain it.

Reclaiming Aggregate Space

• Add disks, or move volumes to an aggregate with free space.
• Shrink volume-guaranteed volumes, or change guarantee type to none — a none-guarantee volume has a much smaller aggregate footprint.
• Delete unneeded Snapshot copies on none-guarantee volumes.
• Delete unneeded volumes.
• Enable deduplication and compression.
• Temporarily disable heavy metadata features while you reclaim space.
• Stop SnapMirror transfers first — they can prevent space reclamation on the aggregate.

Two of those deserve elaboration. Deleting snapshots reclaims nothing on a volume-guaranteed volume, because the guarantee already holds the space; you must relax the guarantee first. And SnapMirror is frequently the hidden consumer: a transfer that is in progress, or a destination snapshot that has not been released, can pin space that the aggregate would otherwise have recovered, which is why "stop replication, watch the numbers move, then resume" is a standard step in a space emergency.

What Not to Do

• Do not disable snapshots globally to buy time. It removes your rollback path at exactly the moment you are about to make changes under pressure.
• Do not delete a qtree or volume in a hurry to see the free-space counter move. Space from deleted snapshots and volumes is reclaimed asynchronously, and the drive rebuild of a RAID group is the real constraint on how fast you can add capacity.
• Do not assume dedupe will save a specific workload. Check the estimated savings on a sample volume before making it part of the plan.

Related Reading

Put this together with ONTAP 去重空间不足排障 for the dedupe-space angle and NetApp ONTAP 日常命令速查 for day-to-day command reference. When the aggregate looks full but the disks look idle, the next place to look is the performance counters described in NetApp ONTAP performance monitoring commands; when capacity is not the issue but growth is, FlexGroup create and expand is the way to scale a namespace beyond one aggregate.

原文链接：https://kb.netapp.com/on-prem/ontap/Ontap_OS/OS-KBs/ONTAP_Space_Usage