磁盘空间排查需分三步：先用df -h看全局占用并检查inode和保留空间，再用du层层下钻定位大目录，最后用find和lsof查大文件及已删未释文件。
磁盘空间突然告警，系统变慢甚至服务中断，问题往往不在“有没有空间”，而在于“空间去哪儿了”。排查不是靠猜，而是有逻辑、分层次的定位过程。核心就三点：看全局、挖局部、查异常。
先看整体占用，锁定问题分区
用 df -h 快速扫一遍所有挂载点，重点关注 Use% 列。数值超过 85% 就该警惕，100% 通常意味着写入失败或服务卡死。注意几个关键细节：
- 同一块物理磁盘可能挂载多个目录（比如 / 和 /home 分开挂载），要逐个检查，别只盯根目录
- 看到 Avail 是 0 但 Size 和 Used 加起来明显小于总容量？那可能是 ext4 默认保留了 5% 空间给 root —— 可用 tune2fs -m 1 /dev/xxx 调低（生产环境建议不低于 1%）
- 顺手加个 df -i，防止是 inode 耗尽（小文件太多时常见），不是空间满，而是“没号可分”
再找大目录，层层下钻定位源头
确定问题分区（比如是 / 或 /var）后，用 du 向下定位。别从头递归全盘扫描，效率低还容易权限报错：
- 查根目录一级子目录： du -sh /* 2>/dev/NULL | sort -hr
- 进可疑目录（如 /var）再查二级： du -sh /var/* 2>/dev/null | sort -hr
- 想快速揪出 G/T 级大户： du -h –max-depth=2 /var | grep ‘[GT]’ | sort -hr
常见“重灾区”有：/var/log（日志疯长）、/var/lib（docker 镜像、数据库数据）、/tmp（临时文件堆积）、/home（用户上传或备份残留）。
接着筛大文件，确认具体元凶
找到大目录后，进一步锁定单个文件。日志、转储、core dump、未清理的安装包最常背锅：
- 查整个分区里大于 500MB 的文件：find /var -type f -size +500M -exec ls -lh {} ; 2>/dev/null
- 专盯日志：find /var/log -name “*.log” -size +100M
- 看最近谁在狂写：ls -lt /var/log/*.log | head -10（按修改时间倒序）
注意：不要直接 rm -f 正被进程打开的日志（如 nginx 或 java 应用写的），得先轮转或重启服务，否则空间不释放。
最后查隐藏异常，解决“看不见”的占用
如果 df -h 显示用了 40G，但所有目录 du 加起来才 15G —— 差的那 25G 很可能被“已删除但仍在占用”的文件吃掉了：
- 运行 lsof +L1 或 lsof | grep deleted，会列出 PID、文件路径（显示为 “(deleted)”）和大小
- 对应进程通常是长期运行的服务（tomcat、nginx、rsyslog），重启它即可释放空间；若不能重启，可尝试清空其日志文件描述符：echo > /proc/PID/fd/N（需 root，慎用）
- 另外检查是否挂载覆盖：比如 /mnt 原来有文件，后来挂了新磁盘，旧文件被盖住却仍占空间 —— 临时 umount /mnt 再 du -sh /mnt 确认
基本上就这些。排查本身不复杂，但容易忽略 df/du 不一致、inode 耗尽、保留空间、已删未释等隐藏因素。养成定期 df -h && df -i 巡检的习惯，比出事再救火强得多。