Linux df 显示磁盘已满但 du 对不上：定位已删除文件的占用句柄

凌晨告警说根分区只剩 2%，可运维同事用 du 逐层相加，怎么也找不到那几十 GB。这里先别急着删日志：df 统计文件系统已经分配的块，du 只遍历目录树里仍能看到的名字。文件被删除后，如果进程还握着打开的文件描述符，目录项消失了，数据块却不会立刻归还。

先确认 df 与 du 观察的是两套数据

先把范围钉在一个文件系统上。假设告警来自根分区，可执行：

df -hT /
df -i /
sudo du -xhd1 / 2>/dev/null | sort -h

-x 让 du 不跨越其他挂载点。若 df -i 的 inode 已用尽，这是“还能看到容量却建不了文件”的另一类问题，不属于本文边界。若块空间接近 100%，而同一挂载点下的 du 总量明显偏小，再检查打开句柄。

从结构上看，df 关心文件系统块和 inode；du 从目录树沿目录项找到可见文件；业务进程则可能通过打开文件描述符继续引用已经没有名字的数据。三个视角并不矛盾。

沿 /proc 找到已删除但仍打开的文件

机器装有 lsof 时，最短的只读查询是：

sudo lsof +L1

+L1 会筛出链接数小于 1 的已打开文件。重点记录命令名、PID、FD、文件大小和原路径，不要看到 (deleted) 就直接杀进程。若没有 lsof，可从 /proc//fd 交叉核对：

sudo find /proc/[0-9]*/fd -lname '* (deleted)' -ls 2>/dev/null
sudo readlink /proc//fd/

/proc//fd 中每个 FD 都是指向真实打开对象的符号链接；已解除目录链接的目标通常带有 (deleted)。再用 PID 查询所属的 systemd 服务，才能把“一个句柄”还原成可控制的业务单元。

用服务级动作释放句柄而不是直接杀进程

处理方式由服务能力决定。会响应日志重开信号的程序，优先按官方运行手册执行 reload；有多副本的服务可先摘流量，再滚动重启单个实例；单实例则应准备维护窗口和回退。用 systemctl status 服务名、进程命令行和部署记录确认归属，别仅凭 PID 猜服务。

直接 kill -9 虽然可能释放块，却跳过了应用清理、请求排空和状态落盘。对数据库、队列或正在写业务文件的进程，这个代价远大于磁盘告警本身。也不要随意向 /proc//fd/ 写零；它会修改进程正在使用的对象，只有在服务官方文档明确支持、并完成备份和审批时才考虑。

反向验证空间是否真正回收

动作完成后，用同一组证据做反向检查：

sudo lsof +L1
df -hT /
systemctl is-active 

合格结果不是“df 数字变小”这一项，而是目标 deleted 句柄消失、文件系统可用空间增加、服务探针和错误日志都正常。若 lsof 已无目标，但 df 没变化，重新确认是不是看错挂载点、快照或容器命名空间；若句柄仍在，说明处理的不是实际持有者。

常见问题

删除大日志后，空间会马上回来吗？

只有没有进程继续打开它时才会。仍有文件描述符引用时，名字消失但数据块继续计入 df。

为什么不建议把重启当第一步？

重启会改变现场，也可能中断业务。先记录 PID、FD、大小和服务归属，才能选择 reload、滚动重启或维护窗口。

容器里 du 正常，宿主机 df 满了怎么办？

容器和宿主机可能处于不同挂载、PID 命名空间。应在告警对应的文件系统和进程视角中查询，不能直接比较两边数字。

df 与 du 对不上时，真正要找的不是“哪个目录还能删”，而是“哪个进程还持有目录树已经看不见的数据”。把文件系统、目录项和进程句柄三条证据连起来，再做服务级释放，处理才安全，也更容易复盘。