ONTAP Quotas: Policy Rules, Resize and Reports

ONTAP quotas are the mechanism that stops one project from filling a shared volume, and they are also the reason a perfectly valid volume shows "quota exceeded" in a log the day after a capacity change. The behaviour is defined by three objects — policies, rules and activation — and by the difference between resizing and reinitialising. This article covers rule creation, the mandatory activation step that most documentation jumps over, and how to read the quota report without misinterpreting it.

Policies, rules and activation

A quota policy is a container of rules. A rule defines a limit for a target, which can be a tree (qtree), a user or a group. A policy is assigned to a volume, and then quotas must be activated on the volume before anything is enforced. NetApp's own documentation states the requirement plainly: for a new rule to be enforced, it must be created in the policy assigned to the volume, and a quota off and quota on, or a quota resize, must then be performed.

Creating rules

cluster1::> volume quota policy rule create -vserver vs0 -policy-name quota_policy_0 -volume vol0 -type tree -target ""

cluster1::> volume quota policy rule create -vserver vs0 -policy-name quota_policy_0 -volume vol0   -type user -target myuser -qtree qtree1 -user-mapping on   -disk-limit 20GB -soft-disk-limit 15.4GB -threshold 15.4GB

cluster1::> volume quota policy rule create -vserver vs0 -policy-name quota_policy_0 -volume vol0   -type group -target engr -qtree qtree1 -file-limit 40000 -soft-file-limit 26500

Notes that matter in practice:

• -target "" with -type tree creates a default tree quota that applies to all qtrees on the volume — useful as a guardrail before you add explicit rules.
• Explicit rules override the default for their target.
• Disk limits are in 4 KB blocks internally, so a value that is not a multiple of 4 KB is rounded up and can look "wrong" in reports.
• The soft limit generates warnings when crossed; the hard limit blocks further writes.

Activation: off/on versus resize

cluster1::> volume quota resize -vserver vs0 -volume vol0
cluster1::> volume quota on -vserver vs0 -volume vol0
cluster1::> volume quota status -vserver vs0 -volume vol0

Always finish with volume quota status. Watch the state field: if quota initialisation is still running, the volume is not fully enforced, and users may briefly exceed limits. On very large volumes, schedule the recount outside business hours.

Reading the quota report

cluster1::> volume quota report
cluster1::> volume quota report -vserver vs0 -volume vol0 -quota-type user -quota-target john -tree q1 -instance
cluster1::> volume quota report -vserver vs0 -volume vol0 -index 10
cluster1::> volume quota policy rule show -vserver vs0

The report lists each active rule with disk used, disk limit, files used, file limit and threshold. Useful options:

• -path /vol/vol0/qtree1/file1.txt shows the rules that apply to a specific file — the fastest way to answer "which quota is blocking this user?".
• -soft expands the soft limits alongside the hard ones.
• -index monitors one entry repeatedly, which is how you track a specific user's growth over time.
• -quota-specifier shows how the target was configured, distinguishing default, explicit and derived rules.

Why enforced limits differ from configured limits

Two effects cause the apparent mismatch:

1. Rounding — limits are rounded up to a 4 KB boundary, so the enforced value is the configured value rounded, not the exact number you typed.
2. Space accounting differences — a UNIX client's du and the quota report count differently (block granularity, sparse files, and snapshot-aware accounting). A discrepancy between the two is expected, not a bug.

Document both effects in your runbook, or you will spend every capacity review explaining why the numbers do not match.

A practical quota rollout

1. Create a default tree quota to establish a baseline guardrail per qtree.
2. Add explicit user or group rules where the business actually needs different allocations.
3. Apply with quota resize, then confirm with quota status.
4. Report weekly with volume quota report and track the top consumers.
5. Set threshold alerts below the soft limit so administrators learn about growth before users hit the wall.
6. When changing policy assignment on a volume, expect a full recount — schedule it.

Common mistakes

• Creating a rule and never activating it — everything looks configured and nothing is enforced.
• Using quota off/on during peak hours on a large volume with millions of files.
• Setting a hard limit below current usage, which silently locks a busy user out on the next write.
• Forgetting that quotas on a SnapMirror destination volume behave differently from the source — test before a real failover.

Monitoring quota usage over time

A quota report is a snapshot of the current state; what operations actually needs is the trend. Three approaches, in increasing order of effort:

• Repeat the report with -index for a handful of high-value targets and log the output. Cheap, and enough to answer "is this user heading for the wall?"
• Export the full report nightly into a time-series system, keyed by volume, qtree and target. This gives capacity forecasting and the evidence needed to justify larger allocations.
• Alert on threshold crossings using the soft limit, so the notification arrives while there is still room to act.

# Recurring check for the top consumers on one volume
cluster1::> volume quota report -vserver vs0 -volume vol0 -sort-by disk-used -fields quota-specifier,disk-used,disk-limit

Watch for two pathologies. A user who perpetually sits just under the hard limit is doing capacity planning on your behalf and will complain, legitimately, about being blocked. A qtree whose usage grows linearly with no seasonality is usually a data lifecycle problem — archive jobs not running, or applications that never delete temporary files.

Worked scenarios

Scenario 1 — the default tree quota is blocking everyone. A default tree quota created as a guardrail applies to every qtree, and if the limit is set at a level meant for the smallest qtree, a large project hits it immediately. Fix by adding an explicit rule for the large qtree rather than raising the default.

cluster1::> volume quota policy rule create -vserver vs0 -policy-name quota_policy_0 -volume vol0   -type tree -target qtree_large -disk-limit 5TB -soft-disk-limit 4.5TB -threshold 4TB
cluster1::> volume quota resize -vserver vs0 -volume vol0

Scenario 2 — a user cannot write despite being under the limit. Check the quota report for the applicable rules including derived ones, then look at the volume's physical space. A quota limit is a policy boundary; it does not create space. If the aggregate or volume is full, writes fail regardless of quota state.

Scenario 3 — quotas vanished after a volume move. Moving a volume between aggregates preserves the policy assignment, but verify it as part of the move checklist. Confirm with volume quota policy rule show and re-run quota resize if usage appears stale.

Scenario 4 — Windows clients report a different usage figure than the report. Expected behaviour: SMB clients and ONTAP account space differently, particularly with offline files, sparse files and alternate data streams. Document the difference so capacity reviews do not become arguments.

Quotas versus other capacity controls

Quotas solve the fairness problem; they do not solve the capacity problem. Treat a quota alert as a signal to have a conversation about allocation, and treat a capacity alert as a signal to plan storage.

Related storage articles

For capacity planning at the aggregate level see ONTAP aggregate space usage, and for day-to-day storage commands use the ONTAP CLI storage cheatsheet. HPE 3PAR equivalents are collected in the 3PAR CLI command cheatsheet.

原文链接：https://docs.netapp.com/us-en/ontap-cli/volume-quota-policy-rule-create.html