Linux 磁盘空间排查：从 df 到定位大文件的完整流程

服务器最常见的半夜告警之一，就是磁盘空间不足。很多人第一反应是直接删文件，或者立刻扩容。更稳妥的顺序是：先确认哪块盘满了，再逐层定位，最后决定清理、轮转还是扩容。

第一步：用 df 看整体。先执行 df -hT，重点看 Use% 和挂载点。根分区满了和数据盘满了，处理方式完全不同；tmpfs 这类内存文件系统一般不用当作磁盘问题处理。看到某个挂载点使用率接近 100%，就把它作为后续排查的起点。

第二步：用 du 逐层下钻。进入可疑的挂载点，执行 du -sh /* 2>/dev/null | sort -h，从最大的目录开始，再进入下一层重复这个动作，直到锁定具体目录。逐层下钻比一上来就全盘扫描更快，也更不容易被无关目录干扰。注意 du 统计的是目录大小，而 df 看的是文件系统层面，两者偶尔会不一致。

第三步：处理 df 与 du 不一致的情况。最常见的原因是文件已经被删除，但仍被某个进程占用，空间因此没有真正释放。这时可以用 lsof | grep deleted 确认，办法通常是重启相关服务，或者让进程重新打开日志文件，而不是继续删文件。

第四步：用 find 直接找大文件。如果怀疑是某个大文件导致的，可以执行 find /var -type f -size +500M -exec ls -lh {} \;，把大文件列出来再逐个判断。日志目录 /var/log、数据库备份目录、应用上传目录，都是常见的重灾区。找到之后先确认文件是否还在用、是否可以归档，能归档的先归档，不要上来就删除。

第五步：清理日志要讲方法。系统日志可以用 journalctl --disk-usage 查看占用，再用 journalctl --vacuum-size=500M 做限制；应用日志建议配置 logrotate，按大小或时间轮转并保留一定份数。只删日志不做轮转，下一次磁盘告警很快又会回来。容器环境还要留意镜像和容器层占用，先用 docker system df 看分布，再谨慎清理。

第六步：别忘了 inode 也会满。磁盘空间除了字节数，还有 inode 数量这一维。如果 df -h 显示还有空间，但写入时仍然报错，就要执行 df -i 看 inode 使用率。大量小文件和未清理的临时文件，都可能把 inode 耗尽。这时要找文件数量最多的目录，而不是单个最大的文件。

最后给一份收尾清单：先定位挂载点，再逐层下钻；删除前确认文件归属和是否在用；日志问题优先做轮转和保留策略；设置 80% 左右的告警阈值，留出处理时间；扩容放在最后，作为确认需求确实增长之后的手段，而不是第一反应。