Write Latency from Locked SnapMirror Copies on a Nearly Full Aggregate
A two-node FAS2750 cluster runs ONTAP 9.10.1. Aggregate aggr1 (24 x 1.8 TB NL-SAS, RAID-DP) hosts 40 volumes and is 94% full. The 6 TB volume vol_eng has a SnapMirror relationship to a DR site that has been unreachable for five weeks; snapmirror show lists the relationship as Broken-off. Snapshot copies on vol_eng consume 2.1 TB, and 14 daily copies are retained. Attempts to remove the oldest SnapMirror copies fail with the message that the Snapshot copy is locked by SnapMirror. Since the aggregate passed 90% capacity, write latency on vol_eng has risen from about 1 ms to 18 ms, and statistics aggregate show reports sustained high disk utilization. Volume autosize is disabled, and the business confirms the DR link will not be restored for three months.
1. Why can the SnapMirror copies not be deleted, and what is the correct release procedure?
Read the worked answer
SnapMirror copies that form the common Snapshot base are locked by the relationship object rather than by the Snapshot policy, so volume snapshot delete refuses while the relationship exists, even in Broken-off state. Identify what is held with snapmirror show -fields status,mirror-state,relationship-id and snapshot show -volume vol_eng -fields owners,create-time,size. Since DR is unreachable for three months and is not serving data, the judgement is to remove the relationship: on the destination cluster run snapmirror break if the relationship still requires it, then snapmirror release -source-path svm_prod:vol_eng -destination-path svm_dr:vol_eng_mirror. Release deletes relationship metadata and makes the previously locked copies deletable; run it on the destination for a mirror, not the source. Note the consequence: re-protecting later requires a full baseline, because the common base no longer exists.
2. Explain the latency increase and rank the remediation options with their trade-offs.
Read the worked answer
WAFL writes are copy-on-write, so near-full aggregates force more allocation work and free-space fragmentation rises; latency climbs well before 100% capacity. Confirm with volume show-space, aggregate show-space, statistics aggregate show -interval 5m and statistics volume show -volume vol_eng -latency. Order: (1) release the relationship and delete obsolete and locked copies, which is fast and free but irreversible for the data removed, so get written sign-off; (2) remove abandoned volumes or clones on aggr1; (3) enable volume autosize and either add disks or move vol_eng to a less-full aggregate with volume move start, which is online but needs destination headroom. Disabling the Snapshot policy is not a fix: it creates no space and removes rollback points. Re-establishing SnapMirror later should follow the release, not precede it.
3. Which guardrails would you put in place so this is caught in days rather than weeks?
Read the worked answer
Add capacity alerting at 80% and 90% on the aggregate, routed to the on-call channel rather than only to a log, and alert on SnapMirror relationship state and lag so a broken link is visible immediately. Enable volume snapshot autodelete with the volume trigger and an appropriate commitment so old copies are removed before the aggregate fills, and align Snapshot policy retention with the actual business requirement instead of leaving 14 dailies by default. Keep a periodic capacity review of Snapshot consumption per volume. Update the DR runbook so a long outage forces an explicit decision to release and re-baseline instead of letting locks accumulate, and test the alert path with a simulated threshold breach so you know the notification reaches someone who acts.