Linux 磁盘空间不足排查：从 df 到大文件定位的四步法

服务器跑着跑着突然告警：磁盘使用率 95%。服务开始报错、日志写不进去、数据库拒绝写入。磁盘满是运维里最常见也最让人慌的故障之一。这篇文章把我自己用熟的一套排查顺序整理出来，四步走完，基本能定位到空间到底被谁吃掉，并安全地释放出来。

第一步：先用 df 看整体，别急着删

第一件事是确认哪个文件系统满了，而不是哪个目录大：

df -h

看 Size、Used、Avail 和 Use% 四列，找到使用率接近 100% 的挂载点，比如根分区 / 或者数据盘 /data。同时可以顺手看一眼 inode 有没有耗尽：

df -i

如果 Use% 不高但 IUse% 已经 100%，那问题是小文件太多（典型如缓存、会话文件堆积），排查方向完全不同。先分清是哪一类，避免删错地方。

第二步：用 du 逐层下钻找大目录

确认满的是哪个挂载点之后，用 du 从该挂载点根部逐层往下找：

du -h --max-depth=1 / 2>/dev/null | sort -hr | head -20

对占用最大的目录继续同样的命令往下钻，一般两三层就能定位到具体的大户：日志目录、备份目录、某个应用的数据目录是最常见的三类。注意 du 统计的是文件实际占用，和 df 的数字对不上时，往往意味着有文件被删除但仍被进程占用，这正是第三步要处理的情况。

第三步：揪出“已删除但仍占空间”的文件

这是最容易被忽略的一类：进程打开着一个大文件（最常见是日志），管理员把文件 rm 掉了，但进程还握着句柄，空间并不会释放，df 看到的占用一直降不下来。用 lsof 可以把它们找出来：

lsof +L1 | grep deleted

处理办法不是再删一次文件，而是让对应进程重新打开文件：平滑重启该服务，或者给进程发送重新打开日志的信号（不少服务支持 kill -HUP 主进程触发日志轮转）。处理完再 df -h 确认空间真正回来。

第四步：日志治理，把复发挡在前面

定位并清理只是治标。磁盘满最常见的元凶是日志无限增长，建议做两件事：第一，给 systemd 日志设上限并定期清理：

journalctl --vacuum-size=500M

并在 /etc/systemd/journald.conf 里设置 SystemMaxUse，避免再次撑爆。第二，检查 /etc/logrotate.d/ 里业务日志的轮转配置是否生效，轮转周期、保留份数、压缩选项是否合理；很多系统是应用自己写日志绕开了 logrotate，这类要在应用侧加大小上限或接入轮转。

小结

排查顺序总结一下：df -h 与 df -i 先定性（空间满还是 inode 满），du 逐层下钻找大目录，lsof +L1 揪已删除仍占用的文件，最后用 journald 上限和 logrotate 把复发挡住。整个过程不需要重启机器，也不需要冒险批量删除；每一步都有明确的验证点，删之前先确认文件用途，这一条比任何命令都重要。