答案是：先用 df - h 和 df - i 判断是否真满或 i node耗尽，再用 lsof +L1 查已删未释放文件，结合 mount 和 du -shx 定位挂载点真实占用，最后检查 ext4 预留空间。
linux磁盘空间看似“满了”，但df 显示已用 100%，du 却加不起来——这非常常见，不是系统出bug，而是几个关键点被忽略了。排查要分两步走：先确认“真满”还是“假满”，再找真正吃空间的源头。
看 df 结果前，先查 i node是否耗尽
磁盘空间没满，但创建文件失败、服务报“No space left on device”，大概率是 inode 用光了。df - h 只看块空间，df - i 才看 inode：
- 运行 df -i，重点关注 IUse% 列，超 95% 就要处理
- inode 耗尽多由海量小文件引起，比如日志碎片、session缓存、未清理的临时文件
- 快速定位：find /var -type f | head -n 10000 | wc -l（估算某目录小文件数量）
- 清理建议：优先删 /tmp、/var/log/journal、/var/lib/php/sessions 等目录下的陈旧小文件
du 算不出空间？可能是“删了但没释放”的文件
文件被 rm 删除，但仍有进程在写它（比如 tail -f 的日志、未重启的 java 应用），空间不会归还。这是新手最常忽略的“隐形占用”：
- 运行 lsof +L1 或 lsof | grep deleted，直接列出已被删除但仍被占用的文件
- 输出中会看到类似 /var/log/app.log (deleted) 和对应 PID
- 解决方法 很简单：杀掉该进程（kill -9 PID）或重启服务（systemctl restart app）
- 注意：不要盲目 kill -9，先用 ps -p PID -o comm= 确认进程名
别只盯 /home /var，先看根目录挂载点真实归属
有时候 du -sh /* 显示 /var 很大，进去一看却没几个大目录——可能 /var 下某个子目录实际是另一个分区的挂载点（比如 /var/lib/docker 挂在了独立 LVM 卷上），du 默认跨分区统计会中断：
- 运行 mount | grep “^/dev”，检查所有挂载点及其设备
- 对比 df -h 输出，确认哪个设备真正满了（比如 /dev/mapper/vg0-lv_docker 占 100%，但挂载在 /var/lib/docker）
- 此时必须 cd 进挂载点再用 du，不能从 /var 开始盲扫
- 额外提醒：如果挂载前目录里已有文件，挂载后它们被“盖住”，卸载后才会暴露——用 umount /path 临时验证
日志和缓存不是唯一元凶，还要防“预留空间”背锅
df 显示 Size 100G、Used 95G、Avail 只有 1G，加起来差 4G？这不是丢失，是 ext4 默认为 root 预留 5% 空间（防止系统彻底卡死）：
- 查看预留比例：tune2fs -l /dev/sda1 | grep “Reserved block count”
- 计算预留量：Reserved block count × Block size ≈ 实际预留 字节 数
- 如确需释放，可调低至 1%：tune2fs -m 1 /dev/sda1（仅限非系统盘或评估过风险后操作）
- 注意：/boot 分区通常很小，5% 预留可能直接吃掉几百 MB，这里调低收益明显
基本上就这些。排查顺序建议固定：df -h → df -i → lsof +L1 → mount → du -shx –max-depth=1 /（- x 跳过其他挂载点）→ 再逐层深入。不复杂但容易忽略。
以上就是 Linux 磁盘空间如何排查_常见误区解析避免新手踩坑【教学】的详细内容，更多请关注 php 中文网其它相关文章！
