NetApp
ONTAP Volume Nearly Full: What to Check Before You Expand It
Start With the Failure Mode
When an ONTAP volume is nearly full, the first instinct is often to expand it. That may be correct, but it should not be the first action. A nearly full volume can be caused by active data growth, snapshot retention, LUN behavior, clone activity, application churn, or a mismatch between the volume's purpose and its policy.
The goal of the first 15 minutes is to answer one question: is this a capacity emergency, a policy problem, or a cleanup opportunity?
Run the First Three Commands
Start by separating active file system usage from snapshot-related usage. If active data is growing, expansion or data movement may be the right fix. If snapshots are consuming unexpected space, the better fix may be retention review, autodelete policy review, or snapshot cleanup.
volume show -vserver <svm> -volume <volume> -fields size,used,available,percent-used
volume snapshot show -vserver <svm> -volume <volume>
volume show-space -vserver <svm> -volume <volume>Use volume show for the fast capacity view, volume snapshot show for snapshot count and age, and volume show-space for the breakdown. Current ONTAP command documentation exposes fields such as user data, snapshot reserve, snapshot spill, total used, physical used, and logical used, which is the split you need before choosing a fix.
Interpret volume show-space
Use the show-space output to decide what problem you actually have.
| Field or Pattern | What It Usually Means | First Response |
|---|---|---|
| User Data is high | Active data is consuming the volume | Confirm owner, growth rate, and expansion target |
| Snapshot Reserve is high | Snapshot reserve is being used as designed | Check policy fit and retention |
| Snapshot Spill is present | Snapshot data exceeded reserve and is using active file system space | Review snapshot age, autodelete policy, and backup dependencies |
| Physical Used differs sharply from Logical Used | Efficiency, compression, compaction, or reserved-write behavior affects the view | Avoid simple "du equals volume used" conclusions |
| Metadata or inode pressure | Filesystem metadata or file count is a factor | Check file-count behavior and workload pattern |
Do not delete snapshots based on percent-used alone. Confirm whether snapshots support SnapMirror, backup software, or a planned rollback point.
Look at Growth Rate
A volume at 88 percent full with slow growth is different from a volume at 88 percent full with a workload adding 500 GB per day. Pull the last few monitoring samples if you have them.
| Signal | Meaning |
|---|---|
| Slow linear growth | Plan expansion or tiering during normal change control |
| Sudden spike | Look for batch jobs, migrations, backups, logs, or application defects |
| Snapshot jump | Review snapshot creation, retention, and churn |
| Flat active data but falling free space | Check snapshot or clone behavior |
If you do not have historical metrics, record the current used/available values and check again in 15 to 30 minutes. That quick delta can change the response.
Check LUN and Host Reclaim Behavior
Block workloads can be confusing because host file deletion does not always return space to the array immediately. Thin LUNs, guest filesystems, databases, and virtualization datastores may need host-side space reclamation or UNMAP behavior before ONTAP sees freed blocks.
Before blaming ONTAP, check:
- Does the host see the filesystem or datastore as full?
- Did someone delete data inside a guest or VMFS datastore without reclaim?
- Is the workload a database that preallocates space?
- Is the LUN thin provisioned or thick provisioned?
- Is storage efficiency running and current?
- Is ONTAP space allocation enabled for the LUN or namespace?
NetApp documents that ONTAP space allocation helps prevent LUNs or NVMe namespaces from being taken offline when space runs out and enables SAN hosts to reclaim space. The default depends on ONTAP version and protocol: ONTAP 9.16.1 and later enables it by default for newly created iSCSI, FC, and NVMe objects; earlier versions differ.
Review Snapshot Policy Fit
Snapshots are valuable, but the policy must match the workload. A high-change volume with frequent snapshots can consume capacity faster than expected.
Ask:
- Is the snapshot frequency appropriate for the recovery objective?
- Is retention longer than the rollback window the application owner needs?
- Did a migration, encryption job, database reindex, or backup job increase block churn?
- Are old manual snapshots still present?
Avoid deleting snapshots blindly. Confirm whether they are needed for backup integration, replication, or a known recovery point.
Check Autosize and Snapshot Autodelete
Before manually expanding the volume, check whether autosize and snapshot autodelete are already configured.
volume autosize -vserver <svm> -volume <volume>
volume snapshot autodelete show -vserver <svm> -volume <volume>
volume show -vserver <svm> -volume <volume> -fields space-mgmt-try-firstONTAP volume autosize supports off, grow, and grow_shrink modes. Current NetApp CLI documentation says new flexible volumes default to autosize off, except data protection mirrors, and that grow / grow_shrink can work with snapshot autodelete. The space-mgmt-try-first setting controls whether ONTAP tries volume growth or snapshot deletion first when both are relevant.
If autosize is off and the workload legitimately needs more room, a controlled expansion may be appropriate. If snapshot autodelete is enabled, confirm the trigger and retention behavior before assuming snapshots are protected from deletion.
Decide Between Cleanup, Expansion, Autosize, and Policy Change
Use this decision model:
| Finding | Likely Action |
|---|---|
| Active data growth is legitimate | Expand volume or move data |
| Old manual snapshots are consuming space | Remove approved snapshots |
| Snapshot policy is too aggressive | Adjust frequency or retention |
| LUN deleted data was not reclaimed | Coordinate host-side reclaim |
| Sudden unexplained growth | Investigate workload before expanding |
| Repeated near-full incidents | Consider autosize with a documented maximum and alerting |
| Snapshot spill is recurring | Review reserve, retention, and autodelete trigger |
Expansion is often the fastest mitigation, but it can hide the root cause. If you expand during an incident, create a follow-up ticket to explain why the space was consumed.
Safe Expansion Pattern
If expansion is the right mitigation, document the current state and set a deliberate target instead of adding arbitrary space.
volume show -vserver <svm> -volume <volume> -fields size,used,available,percent-used
volume modify -vserver <svm> -volume <volume> -size <new-size>
volume show -vserver <svm> -volume <volume> -fields size,used,available,percent-usedFor volumes that repeatedly grow, consider an autosize policy with a maximum size, plus alerts before the maximum is reached.
Minimum Evidence to Capture
- Volume name, SVM, aggregate or tier, current size, used, available, and percent used.
- Snapshot count and oldest snapshot.
- Last known normal capacity value.
- Application owner and workload.
- Immediate mitigation and follow-up action.