Linux 磁盘满了但 du 找不到大文件：deleted 文件占用空间怎么排查

线上机器弹出根分区使用率告警，第一反应通常是找大日志：df -h 一看使用率已经到98%，可 du -sh /* 扫完整个文件夹层级却对不上数值，所有可见文件加起来远没到告警标出的占用大小。这种情况别急着删更多文件，先排查「已经从文件夹里删除，但仍然被进程持有句柄」的文件。Linux 里文件从文件夹列表里消失，不代表磁盘空间会立刻释放；只要还有进程握着对应的文件句柄，占用的空间就不会被回收。

先确认 df 告警的是哪个挂载点

排查磁盘满问题，第一步不是直接跑 du 扫全盘文件夹，而是先确认到底哪个文件系统挂载点满了。很多服务器有单独的 /data、/var、容器专属挂载路径或者独立数据盘，查错挂载点会浪费大量排查时间。

df -h
df -ih

df -h 看块容量使用率，df -ih 看 inode 占用率。容量满和 inode 满是两类完全不同的问题，最终表现都可能是「新文件写不进去」。如果块容量还有剩余但 inode 已经100%，就要去查大量零散小文件；如果块容量已经接近100%，再继续往下排查文件夹或进程的占用。

对比 du 统计结果：文件夹统计数值为什么对不上

确认出问题的挂载点以后，再单独针对这个挂载点做文件夹占用统计。比如根分区满了，可以先扫根路径下的一级子文件夹；如果是 /var 分区满了，就只扫 /var 路径下的内容，不要把其他挂载点的占用混进统计结果里。

du -xhd1 /
du -xhd1 /var | sort -h

-x 的作用是限定统计范围留在当前文件系统内，避免统计过程中跳转到其他挂载点。这里如果发现 du 统计出来的所有文件夹总占用，明显小于 df 显示的已用容量，比如 df 显示已经用了 80G，但所有可见文件夹加起来只有 45G，就要把排查方向转向被标记为 deleted 的已删文件和进程持有的文件句柄。

用 lsof +L1 定位 deleted 文件

能直接把这类场景定位清楚的常用命令是 lsof +L1。它会列出所有硬链接数小于 1、但仍然被进程打开的文件，输出结果里会直接看到 deleted 标记。

lsof +L1
lsof +L1 | sort -k7 -n

重点看输出里的三列内容：进程名、PID、文件大小。比如某个 Java 服务、Nginx 工作进程或者自研后端进程，还持有着一个已经从文件夹里删除的 access.log，这个文件现在在文件夹里已经完全看不到，du 统计的时候自然扫不到它，但对应的磁盘空间还被文件系统持续占用。

释放空间前先确认 PID 对应的服务归属

找到占用 deleted 文件的 PID 以后，不要马上 kill -9 操作。先确认这个进程属于哪个业务服务、有没有配置守护进程、是否支持安全重启。生产环境里，重启一个普通日志采集服务和杀掉正在运行的数据库主进程，风险级别完全不同。

ps -fp 1234
readlink /proc/1234/exe
ls -l /proc/1234/fd | grep deleted

如果确认是普通业务服务持有已经删除的旧日志，优先用对应服务的管理命令重启，让它重新生成并打开新的日志文件。systemd 管理的服务可以用 systemctl restart app.service 操作；如果是 Nginx 这类本身支持平滑重载的服务，优先使用它自带的 reload 或者 reopen 日志指令来释放旧句柄。

反向验证：空间是不是真的成功回收

服务重启或者旧文件句柄释放完成以后，再执行一遍 df 查看结果。如果这些 deleted 文件就是占满磁盘的根因，使用率会立刻下降。这里建议顺手核对业务服务的新日志是否可以正常写入，避免空间恢复之后，服务日志再也无法生成写入的次生问题。

df -h
lsof +L1
journalctl -u app.service -n 50 --no-pager

如果 lsof +L1 的输出里还有大体积的 deleted 项，说明仍有进程没有释放对应句柄；如果所有 deleted 项已经消失但磁盘占用还是满的，再回头走 du 和 inode 检查流程，继续排查真实文件夹占用、容器 overlay 层、过期日志轮转文件或者系统快照残留。

后续运维清单：避免同类问题反复出现

• 大体积日志文件不要直接手工 rm 删除，优先走标准日志切割流程，再触发服务 reload 释放旧句柄。
• 给关键分区配置容量和 inode 双指标告警，不要只监控单一使用率指标。
• 检查日志轮转配置里的 copytruncate、postrotate、重载命令是否匹配当前运行的服务类型。
• 容器环境排查要同时核查宿主机路径、容器内存储路径和 overlay 层的实际占用。
• 处理完磁盘满故障之后，把关联的 PID、被占用文件名、释放方式和恢复前后的容量数值记录下来，方便后续同类问题快速排查。

常见问题

为什么 rm 删除大日志文件以后 df 显示的使用率还是满的？

大概率是还有进程保持着这个日志文件的打开状态。文件在文件夹里的条目已经被删掉了，但进程持有的文件句柄没有关闭，对应的磁盘空间不会立刻归还给文件系统。

能不能直接清空 /proc/PID/fd 路径下的 deleted 文件？

不建议随手做这类操作。更稳妥的方式是先确认对应服务的业务归属，评估影响后再重启服务或者触发服务重新打开新日志。对关键进程的 fd 做修改前要先做好风险评估。

du 和 df 统计出来的占用数值永远都应该一致吗？

不一定。两者统计口径本来就不同，跨挂载点统计、权限限制、deleted 未释放文件、隐藏文件夹和文件系统预留空间都会造成数值差异。

容器内部看到磁盘满，也能用这套方法排查吗？

可以先用相同的思路走一遍排查流程，但还要额外核查宿主机的 overlay 占用、容器标准输出日志和数据卷挂载情况。容器内看到的存储路径，未必就是宿主机上真正占用磁盘空间的对应位置。