df 显示占 98% 但 du 加总只有 60%：已删除仍被进程持有的文件占满磁盘的排查与释放

结论先行：df 和 du 对不上、磁盘明明"看着还有空间"却写不进去，十有八九不是文件系统坏了，而是有进程还攥着一个已经被 unlink 删掉的大文件不放——目录项没了（所以 du 扫不到它），但 inode 和数据块因为还被文件描述符引用着，内核不肯释放，空间就这么凭空"消失"了。

一、现象：du 加总比 df 少了 41GB，日志目录写满报 ENOSPC

上周三 14:20，监控告警：一台跑日志采集的机器（CentOS 7.9，内核 3.10.0-1160，XFS，系统盘 100GB）/data 分区使用率飙到 98%，业务侧 filebeat 报 No space left on device，采集断流 11 分钟。

我登上去第一反应是 df -h：

Filesystem      Size  Used Avail Use%
/dev/vdb        100G   97G  2.1G  98%

97G 已用、只剩 2.1G——确实满了。但诡异的是我 du -sh /data/* 一路加总，所有目录加起来只有 56G。也就是说，有约 41GB 的空间被占用了，但 du 一个字节都找不到它。

更迷惑的是：df -i 一看，inode 使用率才 3%，根本不是 inode 耗尽（这个我上一篇讲过，这次不是同一个病）。空间实打实被吃了，就是查不到归属。

二、原理：unlink 删的是"门牌"，不是"房子"

把文件想成一栋房子：

• 目录项（dentry）= 门牌号。rm / unlink 做的就是把门牌号摘掉，从此你按路径找不到它了——du 走的是路径遍历，所以它看不见这个文件，自然加总不出来。
• inode + 数据块 = 房子本身。房子什么时候拆？取决于还有没有人拿着钥匙（文件描述符 fd）站在屋里。

POSIX 的语义是：只要还有任何一个进程持有这个文件的打开 fd，内核就不会释放它的 inode 和数据块，哪怕目录项已经被删光。于是出现这种分裂状态——文件在文件系统里"已不存在"，但空间被钉死在那里。

这类文件会出现在 /proc/<pid>/fd/ 下，路径后面带一个 (deleted) 标记。这就是 df（看的是块设备实际占用，含这些幽灵文件）和 du（走目录树，看不见它们）差出 41GB 的根因。

三、具体做法：三步定位 + 两种释放

第 1 步，确认是不是"已删除仍打开"：

# 最快：直接找带 deleted 的 fd
lsof 2>/dev/null | grep -w deleted
# 或看全系统所有已删除但仍打开的文件（含大小）
find /proc/*/fd -ls 2>/dev/null | grep deleted

我们当时跑 lsof | grep -w deleted，立刻抓到一条：

java  18412  app  3w  REG  253,0  41213424640  0 ... /data/logs/app-2024-xx-xx.log (deleted)

一个 41.2GB 的日志文件，进程 18412 还攥着它的写端 fd 3。问题清楚了：日志轮转脚本把旧 log rename 后又 unlink 了，但 Java 进程的 log4j 还开着这个句柄没重开，轮转等于白转。

第 2 步，释放空间（不重启进程）：

# 用 truncate 把那个"幽灵文件"清零，空间立刻回来
> /proc/18412/fd/3
# 或
truncate -s 0 /proc/18412/fd/3

执行后 df -h 立刻从 98% 掉到 54%，filebeat 恢复采集，全程没动业务进程。

第 3 步，治本： 把日志轮转从"unlink 旧文件"改成"log4j/logback 的 RollingFileAppender 自己滚动 + 保留 N 份"，并给 maxFileSize/totalSizeCap 设上限（我们设 totalSizeCap=20GB），从根上不让单个进程持有一个无限增长的句柄。

四、踩过的坑 & 反直觉点

1. > /proc/PID/fd/N 不是万能的。 如果那个 fd 是 O_APPEND 打开的，truncate 之后进程下一次写会从头再写、空间照样涨（只是不再"消失"）。对 append 型日志，正解是让应用侧改轮转策略，而不是 truncate 续命。
2. 别拿 du 不准当借口。 很多人第一反应是"du 有 bug / 统计口径问题"，浪费半小时。du 没错，是它按路径遍历、天生看不见无路径的幽灵文件。看到 df/du 差一大截，直接奔 lsof | grep deleted 才快。
3. lsof 在大机器上会慢（我们这台 100GB、几十万 fd 跑了一次约 20 秒）。想更快就用 find /proc/*/fd -ls | grep deleted，或 slurpfile/nfsiostat 之外的 cat /proc/<pid>/fdinfo/*。
4. 和 inode 耗尽是两种病，别混。 inode 耗尽是"小文件太多、卡片用完"（df -i 100%）；这个是"一个大文件被删了但没释放"（df -h 满、df -i 正常）。先看 df -i，一眼能分流。
5. kill 进程也能释放，但代价大。 杀掉持有 fd 的进程，内核会关闭所有 fd、释放空间——但这等于把业务进程一起干掉，生产上优先用 truncate 续命 + 事后改配置，别动不动重启。

五、结论与可复用清单

• 判据：df -h 使用率很高、df -i 正常、但 du 加总明显偏小 → 第一嫌疑就是"已删除仍打开"的文件，别去怀疑文件系统或 du。
• 定位三板斧：lsof | grep -w deleted → find /proc/*/fd -ls | grep deleted → 看 fd 归属进程和大小。
• 止血：truncate -s 0 /proc/<PID>/<fd>（非 append 句柄秒级释放）；append 型则推动应用改轮转。
• 治本：所有会写大文件的组件，日志/临时文件一律用应用自带滚动 + 总容量上限（totalSizeCap），禁止脚本 rm 掉仍被进程持有的文件。
• 监控：给每个数据盘加一条"df 使用率"告警，再加一条 du / 定时采集，两者差值超过阈值（比如 5GB）就单独告警——这个差值本身就是"幽灵文件"的早期信号，能比 ENOSPC 早几分钟发现。

一句话：df 和 du 对不上，多半是有人删了门牌但还住在屋里。找到那个攥着 fd 的进程，truncate 一下，空间就回来了。