Thin pool exhaustion with snapshot growth
A 300 TB usable storage pool supports 40 thin LUNs totaling 420 TB subscribed capacity. The pool currently has 18 TB free. Hosts write about 2 TB per day of new data, and the change rate is 0.5% per day. Snapshot retention is 30 days, snapshots consume 45 TB, and automatic snapshot deletion is disabled. Pool high-water alarms are set at 85% and 95%; the pool is at 94%. A new 10 TB thin LUN is requested for a project that will write 1 TB per day for the next 14 days. The team must decide whether to expand the pool, delete snapshots, or reject the request. Deleting all snapshots would free 45 TB but violates the recovery policy. No deduplication or compression is enabled; RAID6 overhead is already accounted for.
1. Estimate the net daily pool growth and the runway to 100% under current snapshots. Show assumptions.
Read the worked answer
Used capacity = 300 − 18 = 282 TB. At 0.5% daily change, snapshot copy-on-write growth is about 282 × 0.005 = 1.41 TB/day. Add 2 TB/day of new host writes for a net pool growth of about 3.41 TB/day, assuming no reclaim and that the oldest snapshots do not yet expire. Runway to 100% = 18 / 3.41 ≈ 5.3 days. This is an estimate: snapshot growth depends on overwrite locality and whether multiple snapshots reference the same blocks; if changes are concentrated, growth can be lower, but if the new project rewrites existing blocks, it can be higher. The 94% alarm means there is very little time for approvals. Treat the 5-day runway as an upper bound and act before the 95% alarm, because pool full can take LUNs offline and snapshots may be invalidated.
2. Evaluate the 10 TB request and recommend an action plan. Include calculations for the first 14 days and snapshot policy.
Read the worked answer
With the new 10 TB LUN writing 1 TB/day, net growth becomes 4.41 TB/day. The 18 TB free gives 18 / 4.41 ≈ 4.1 days. Over 14 days, demand is 14 × 4.41 ≈ 61.7 TB; after using the 18 TB free, the pool is short about 43.7 TB. Deleting all snapshots frees 45 TB, giving 63 TB free, but at 4.41 TB/day that is only about 14.3 days and leaves no safety margin; it also violates the 30-day recovery policy. Reject the request as submitted. Expand the pool by at least 64 TB (preferably 80 TB with 10–15% headroom), or reduce the request to 5 TB and shorten snapshot retention only with business approval. Enable automatic snapshot deletion at a high-water mark, but keep a minimum 7-day retention, and monitor daily.
3. What leading indicators would you monitor to avoid a repeat, and why is pool free capacity alone insufficient?
Read the worked answer
Monitor snapshot consumption rate and snapshot age, per-LUN write/change rate, thin subscription versus pool used, overcommit ratio, and projected days-to-full using a 7-day trend. Free capacity alone is insufficient because it is a lagging indicator and can look stable while snapshot references silently consume space that will not be freed until the oldest snapshot expires. Also watch deleted-but-not-reclaimed blocks, pool metadata usage, and auto-delete events. Set alerts at 70%, 80%, and 85% with a forecast, not only at 85% and 95%; at 94% the remaining time is too short for change control. Review the 140% overcommit against actual growth, and reclaim unused thin LUNs before adding capacity. Leading indicators are change rate and snapshot growth, not the current free TB.