答案是：先用df -h和df -i判断是否真满或inode耗尽，再用lsof +L1查已删未释放文件，结合mount和du -shx定位挂载点真实占用，最后检查ext4预留空间。
Linux磁盘空间看似“满了”，但df显示已用100%，du却加不起来——这非常常见，不是系统出bug，而是几个关键点被忽略了。排查要分两步走：先确认“真满”还是“假满”，再找真正吃空间的源头。
看df结果前，先查inode是否耗尽
磁盘空间没满，但创建文件失败、服务报“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跳过其他挂载点）→ 再逐层深入。不复杂但容易忽略。
