删除文件后空间不释放是怎么回事
在 Linux 上删除文件实际是减少链接计数：如果仍有进程持有该文件的句柄，数据块不会真正释放，df 显示的可用空间就不会增加。典型场景是日志文件被手工删除而写日志的进程还在运行，文件在枚举中已经看不到，空间却一直占着。定位方式是查找处于已删除状态但仍被打开的句柄，稳妥的回收办法是让持有进程重新打开文件，通常是滚动重启该进程。
基本信息
| 定位命令 | lsof +L1 列出已删除但未关闭的句柄 |
|---|---|
| 统计视角 | 按命令聚合统计占用规模 |
| 回收方式 | 重启或重载持有句柄的进程 |
| 根因预防 | 配置日志轮转，避免手工删除日志 |
| 判断依据 | df 与 du 数字差距明显 |
典型使用场景
- 手工删除了大日志文件，df 仍显示空间紧张
- 空间告警处置后发现释放量远小于预期，需要解释差异
- 服务重启后空间自动恢复，确认是句柄未释放导致
- 排查长期运行进程持有的历史文件，评估是否需要重载
- 为日志型应用设计轮转与重载方案，从根本上避免问题
- 容量统计中出现「消失的空间」，需要给出可核对的技术解释
定位与回收
定位与回收
df -h /var # 确认可用空间与预期是否相符
lsof +L1 | head -20 # 列出已删除但未关闭的句柄
lsof +L1 | awk '{print $1}' | sort | uniq -c | sort -rn | head # 按命令聚合
lsof +L1 | awk '{print $7, $1, $2}' | sort -rn | head # 看占用大小排行
# 稳妥做法：滚动重启持有句柄的进程，回收空间
systemctl restart app-web
# 日志型应用重载后重新打开文件，效果类似且中断更小
# 不建议直接操作 /proc/<pid>/fd：可能破坏应用状态
lsof -p <PID> | head # 确认进程当前打开的文件现象与原因对照
| 现象 | 原因 | 处理 |
|---|---|---|
| 删除后空间不降 | 进程仍持有句柄 | 重启或重载该进程 |
| df 与 du 差距大 | 存在已删除但打开的文件 | 用 lsof +L1 定位 |
| 重启服务后空间恢复 | 句柄被释放 | 配置轮转避免再次发生 |
| 日志持续增长不轮转 | 缺少轮转策略 | 补齐 logrotate 或等价机制 |
| 空间被占但找不到文件 | 文件已在枚举中消失 | 从进程句柄角度排查 |
日志文件删除后空间不释放是最常见的形态；把日志轮转配好并让进程在轮转后重新打开文件，可以从机制上避免反复出现同类问题。
重启持有句柄的进程前评估业务可中断性：大内存服务重启窗口较长，应安排在维护窗口内进行，而不是在告警压力下临时执行。