AFF/FAS FlexVol capacity incident · NAS or LUN-containing volumes
Illustrative incident: Projects reports failed writes. The volume is 98% used, and the containing aggregate is also under pressure. The administrator needs to restore service while preserving approved Snapshots and replication. The numerical examples below are a worksheet, not output captured from a storage system.
About the command and output examples
Names, addresses and results are illustrative. Commands have not been executed against a live storage system or SAN switch for this publication. Confirm syntax and compatibility for your release, then rehearse in an approved lab. Existing-data recovery and destructive changes need an environment-specific plan. Read the editorial standards.
01Establish what is failing and stop unnecessary growth
- Capture the first failure time, affected application, exact error, SVM, volume and aggregate. Check whether reads still work and whether one client or every writer is affected.
- Ask the application owner to pause an optional bulk import or backup staging job if it is the confirmed growth source. Preserve essential application writes according to the incident plan. Do not use unapproved file deletion as a first response.
- Compare the client-visible free space with ONTAP volume usage, volume footprint and aggregate physical usage. Thin provisioning and storage efficiency mean those views can differ.
volume show -vserver svm_prod -volume vol_projects
volume show-space -vserver svm_prod -volume vol_projects
volume show-footprint -vserver svm_prod -volume vol_projects
storage aggregate show
storage aggregate show-space -aggregate aggr_data
event log show -severity ERRORThe incident is assigned to volume capacity, aggregate capacity, quota, or another specific failure domain.
02Interpret the three capacity views
If the volume is at its limit but the aggregate has adequate physical headroom, a controlled volume growth may restore service. If the aggregate is exhausted, increasing a thin volume size can make the display look better without creating usable physical capacity. A SAN guest may still show free filesystem space while its containing storage cannot accept new blocks.
| View | Question answered | Common trap |
|---|---|---|
| Client/volume free space | Can the namespace or LUN volume accept more logical data? | Client free space does not prove aggregate physical space. |
| Volume show-space | Which categories consume this volume? | Do not add overlapping counters as if they are independent. |
| Volume footprint | How much aggregate allocation is attributable to this volume? | Logical volume size is not the same as physical footprint. |
| Aggregate show-space | Can the storage pool fund writes and metadata? | Growing a thin volume does not add physical storage. |
| Quota report if enabled | Has this user or qtree reached a limit? | A quota denial can occur while volume space is free. |
03Calculate the runway instead of selecting an arbitrary size
Use the observed growth during the incident and a conservative operational reserve. Do not budget on an assumed deduplication ratio for new data. The example uses GiB consistently; convert your recorded units before calculating.
| Illustrative quantity | Value |
|---|---|
| Measured remaining physical free space | 400 GiB |
| Operational reserve chosen for the example | 150 GiB |
| Recent net growth | 25 GiB per hour |
| Usable incident runway | (400 − 150) / 25 = 10 hours |
- Repeat the measurement to ensure growth is still approximately linear. Include the next backup, snapshot or replication cycle in the forecast.
- Set a decision deadline before the reserve is reached. If the workload has bursty writes, use its peak period and a larger buffer rather than relying on this linear example.
- Record what will add real capacity or reduce approved consumption before that deadline: volume move to a pool with headroom, verified capacity expansion, or owner-approved cleanup.
The incident record contains a measured growth rate, reserve, next peak event and capacity action deadline.
04Select the narrowest valid corrective action
A snapshot can retain blocks belonging to files that have been deleted from the active filesystem. Deleting one recovery point does not guarantee that its displayed size becomes free space: other snapshots, clones or protection dependencies may still reference blocks. Predict the effect using the supported accounting tools and verify the actual reclaim afterward.
| Confirmed condition | Candidate action | Evidence needed first |
|---|---|---|
| Only volume limit reached | Increase the specific volume within the approved plan | Aggregate headroom, guarantees and other volume commitments |
| Aggregate physical space exhausted | Add supported capacity or move an eligible volume | Destination headroom, supported platform procedure and performance impact |
| Obsolete data is approved for removal | Delete the specifically authorized files | Application ownership and recovery/retention requirements |
| Snapshot retention is the proposed target | Review recoverable points and dependencies before removal | Backup/SnapMirror owner approval and expected reclaimable space |
| Quota limit reached | Correct an approved quota or workload allocation | Quota report and ownership, rather than arbitrary volume growth |
volume size -vserver svm_prod -volume vol_projects -new-size <approved_new_size>
volume show -vserver svm_prod -volume vol_projects
storage aggregate show-space -aggregate aggr_data05Validate writes, protection and the next capacity cycle
- Repeat the original failed write as the application identity and verify that the application can read the result. A successful new test file alone may not cover an application transaction or guest filesystem failure.
- Recheck the volume, aggregate, quotas if applicable, new EMS events and SnapMirror status. Confirm that protection was not inadvertently disabled during emergency recovery.
- Observe the next snapshot/transfer/backup cycle and compare free space again. If usage rises faster than the forecast, reopen the incident rather than treating the temporary expansion as the final fix.
Application writes are restored, physical headroom remains above the chosen reserve, and required protection still works.
06Turn the incident into a capacity decision
A useful closure explains why growth was not caught. For example: a new import wrote 25 GiB/hour, but alerts only watched logical volume use once a day; the aggregate crossed its reserve between checks. The preventive change is a growth-rate alert and ownership of the import capacity plan, not simply a higher percentage threshold.
- Record cause, affected volumes, logical/physical usage before and after, the approved action and restored service time.
- Assign the permanent capacity or cleanup action to an owner with a due date. Document which recovery points were retained and any exceptional deletion approval.
- Compare the new forecast with the measured trend during the following operational review.
Use the section links to revisit a step, or follow a related guide below.
Official references and further reading
Choose the matching release in the vendor documentation before using a command or design. References open on the publisher’s website; linked material remains with its publisher.