回收链路为什么常断
空间的回收是一条链：应用删除文件、文件系统释放块、块设备把「这些块不再使用」的提示传给存储、存储层据此回收精简置备或快照占用的物理空间。链上任何一环不支持或被关闭，使用者就会发现「删了很多数据，用量几乎没动」。快照会持有旧数据块引用、被进程占用的已删除文件、未启用回收提示的精简卷，都是最常见的断点。
基本信息
| 回收链路 | 应用删除 → 文件系统释放 → 块设备提示 → 存储层回收，逐层生效 |
|---|---|
| 各层条件 | 文件系统与块设备需支持并启用回收提示，精简置备卷需允许空间回收 |
| 常见占用来源 | 快照持有旧块引用、进程占用的已删除文件、日志与临时文件、备份副本 |
| 治理手段 | 定期清理与保留策略、启用回收提示、清理快照、设置配额与上限 |
| 判读方式 | 对比删除量与实际回收量，逐层定位卡在哪一环 |
| 验证方法 | 在受控卷上执行一次回收并观察用量变化，确认链路有效 |
典型使用场景
- 容量告警触发但业务方反馈数据早已删除，需要解释与定位时
- 精简置备池水位高，业务侧删除后水位不降，排查回收链路时
- 快照链过深占用空间，需要评估清理收益时
- 批量日志或临时文件清理，验证清理是否真正释放了空间时
- 建立容量治理机制，把回收动作纳入日常巡检时
逐层定位回收断点
逐层定位回收断点
# 文件系统层：目录占用是否真的下降
du -x -h --max-depth=1 /data | sort -h | tail
# 已删除但仍被进程持有的文件，删了也不会释放空间
lsof +L1 | head -20
# 主动触发回收提示（对支持的精简卷与文件系统有效）
fstrim -v /data
# LVM 精简池：观察数据占用比例是否随回收下降
lvs -a -o name,lv_size,data_percent
# 快照占用与保留策略需在阵列侧查看，字段名以厂商文档为准回收环节与卡点
| 环节 | 何时释放 | 卡住的表现 |
|---|---|---|
| 应用层 | 删除文件即刻 | 日志与备份副本仍在，用量不降 |
| 文件系统 | 释放块但未必通知底层 | 目录变小但底层用量不动 |
| 块设备提示 | 需启用回收能力 | 精简层看不到空闲块 |
| 存储层 | 收到提示后回收 | 快照持有引用导致无法回收 |
回收效果必须实测：在受控卷上删除一批数据并触发回收，观察用量变化曲线。只看理论支持而没验证过链路，真到容量紧张时很可能发现回收并不生效。
精简置备场景下回收失败会让池水位持续上升，最终在全池范围触发写入失败。因此回收能力应与容量阈值、扩容易一起纳入容量治理，而不是当成一次性清理动作。