Folder-level growth monitoring in ONTAP

ONTAP capacity dashboards naturally start at aggregate and volume scope. To answer “which folder grew?”, first define a measurable boundary, then retain time-series samples outside the cluster.

The short answer

ONTAP does not turn every arbitrary directory into a historical capacity metric. For durable server-side accounting, place a workload at a qtree boundary and use tree quotas. For an ordinary nested folder, scan it from a NAS client or collector. In either case, a growth rate exists only after something stores repeated, timestamped samples.

volume show answers how a volume changed; it cannot identify the subdirectory responsible. volume quota report reports current usage for enforced quota targets, including qtrees. Neither command is a history database. A weekly volume report therefore cannot reconstruct daily folder growth after the fact.

Choose the boundary before the tool

Question	Best boundary	Collection method
Which top-level project is growing?	One qtree per project	Tree-quota usage via CLI or REST, sampled centrally
Which existing nested folder grew?	Directory path	Scheduled client-side filesystem scan
Which user owns the growth?	User or group quota target	Quota report; validate identity mapping
Which files changed?	File inventory	Client/analytics index; not a volume counter

Architecture matters: a qtree is an administrative boundary, not a cosmetic rename of an existing directory. Plan data placement, export/share behavior, security style, backup, and application paths before migrating content into one.

Qtree and quota workflow

1. Inspect what already exists

cluster::> volume qtree show -vserver svm1 -volume data
cluster::> volume quota show -vserver svm1 -volume data
cluster::> volume quota policy rule show -vserver svm1 -volume data
cluster::> volume quota report -vserver svm1 -volume data -type tree

The policy-rule view shows configuration. The report shows enforced targets and current disk/file usage. If quota state is off or still initializing, do not treat a missing report row as zero use.

2. Add reporting-only tree accounting

This example assumes qtree project_alpha already exists and the SVM uses quota policy default. The unlimited values collect usage without imposing a hard or soft cap.

cluster::> volume quota policy rule create -vserver svm1 \
  -policy-name default -volume data -type tree \
  -target project_alpha -disk-limit - -file-limit -

cluster::> volume quota resize -vserver svm1 -volume data
cluster::> job show
cluster::> volume quota show -vserver svm1 -volume data -instance
cluster::> volume quota report -vserver svm1 -volume data \
  -type tree -tree project_alpha

volume quota resize creates a job and requires quotas to be active. NetApp documents cases where a new definition requires quota reinitialization rather than a resize; inspect errors and follow the release-specific quota procedure instead of repeatedly toggling quotas on production data.

3. Make limits an explicit second decision

Monitoring and enforcement are different changes. After observing a defensible peak and agreeing on headroom, modify the policy rule with release-appropriate -soft-disk-limit, -threshold, or -disk-limit values, then resize and verify the effective report. Do not copy a sample limit into production.

Ordinary folders: measure from the client side

For NFS or SMB directories that cannot become qtrees, run the scan from a host with a stable mount, a service identity that can traverse the complete tree, and tooling appropriate to that operating system. Record failures and duration with every sample: “12 TiB” is misleading if permissions hid part of the tree or the scan timed out.

# Linux example after mounting the export; GNU du syntax
du -sx --block-size=1 /mnt/data/team-a

# Capture both allocation and apparent (logical) size when that distinction matters
du -sx --block-size=1 /mnt/data/team-a
du -sx --apparent-size --block-size=1 /mnt/data/team-a

These are client commands, not ONTAP CLI. Exact flags vary by operating system. Full-tree scans can be expensive in metadata-heavy namespaces, so test their effect and schedule accordingly. The ONTAP command volume file show-disk-usage accepts a file path and can show total and unique bytes for that file; it is not documented as a recursive arbitrary-directory growth scanner.

Turn point-in-time usage into a growth trend

Sample at a fixed cadence and keep UTC timestamp, cluster, SVM, volume, target/path, used bytes, file count, method, status, and duration.
Store raw integer bytes; format TiB only in presentation.
Calculate growth = current_used_bytes - previous_used_bytes. Divide by elapsed days only when both samples completed successfully.
Alert on both remaining headroom and growth rate. A shrinking folder can still sit dangerously close to a hard limit.
Retain enough history to cover monthly, quarterly, and known seasonal cycles.

timestamp_utc,svm,volume,target,used_bytes,files,status
2026-09-01T00:00:00Z,svm1,data,project_alpha,VALUE_FROM_REPORT,COUNT,ok

The REST API can retrieve storage quota reports for automation; endpoint fields and availability vary by ONTAP release. Discover the schema on the target cluster and pin collectors to documented fields. Never scrape human-formatted CLI columns when a supported structured interface is available.

Interpretation pitfalls

Logical versus physical: quota usage, client apparent size, client allocated blocks, volume logical used, and aggregate physical use answer different questions. Deduplication, compression, clones, sparse files, and Snapshot retention prevent one-to-one comparison.
Deletes: a directory can shrink while Snapshot-held blocks keep physical consumption from falling.
Moves and renames: moving data between tracked boundaries creates a drop and spike without new data being written.
In-flight writes: client scans are not atomic snapshots. For strict comparisons, scan consistent Snapshot-mounted views if your workflow supports them.
FlexGroup: confirm quota support and reporting behavior for the exact ONTAP release and volume type; do not assume a FlexVol procedure maps unchanged.

Operational rule: label every chart with its accounting method. “Qtree quota used bytes” and “client apparent bytes below this path” should never share an unlabeled series.

Primary sources and currency

Reviewed 9 September 2026 against ONTAP 9.17.1 command documentation. Validate syntax and feature support against the exact release and volume type you operate.