## 案例现场
某天磁盘告警：df 显示数据盘 100%。运维登上去排查，du 把目录翻了个底朝天，所有可见文件加起来只占六成，剩下四成去向不明。删掉了几个日志也无济于事，df 纹丝不动。磁盘像被看不见的东西占着，业务还在正常写入，眼看就要写满停摆。
## 根因分析
谜底在 Linux 的删除语义：rm 解除文件名与 inode 的关联，但只要还有进程握着这个文件的打开句柄，数据块就不会释放。df 统计的是文件系统的块占用（含被删未释放的），du 只统计有名字的文件，两边对不上，差值就是"已删除但仍被占用"的空间。本案的肇事者后来确认是一个被误操作 rm 掉、但 Java 进程仍握着句柄继续写的日志文件，体积已经滚到几十个 G。容器环境同样有这个坑：容器日志被删但进程还握着句柄，宿主机数据盘照样被占。
## 修复过程
第一步定位，列出所有已删除仍被占用的文件：
bash lsof | grep deleted
输出按大小排序找到大户，确认它挂在哪个进程名下。第二步释放，最干净的方式是重启持有句柄的进程：安排业务低峰重启该 Java 服务，句柄归零，空间立即归还，df 恢复正常。不想立即重启的应急办法是从 /proc 里对句柄做清空操作，把文件内容截断为零，空间回来大半，进程无需动。重启前先截取进程的日志尾部，重启后对照写入是否正常恢复。第三步验证，df 与 du 的差值回到正常范围，写入恢复正常。
## 复盘要点
直接的教训是日志管理：删除永远不是日志的归宿，truncate 与 logrotate 轮转才是，轮转后的切割信号让进程按新文件写，句柄问题从机制上消除。深一层的教训是监控：df 与 du 的差值本身应该被监控，差值持续扩大就是在积累隐形炸弹。在顺云的云服务器上把这条检查写进巡检脚本，加上磁盘告警的分档配置，同类问题不会再等到写满才发现。重要进程的日志路径集中规划，异常增长本身也配上告警。