No space left on device 常因 inode 耗尽、僵尸文件或挂载点嵌套导致，而非磁盘空间真正占满；需依次执行 df -h、df -i、lsof +L1、mount 和 du -shx 排查。
直接说结论：No space left on device 不等于 df -h 显示 100% 空间 —— 很可能磁盘还有几十 GB 剩余，但 inode 耗尽、或有被进程占用的“僵尸文件”、或挂载点嵌套遮挡了真实空间，这三类情况占实际线上问题的 80% 以上。
检查 inode 是否已满（最常被忽略）
磁盘空间充足却报错，第一反应必须是查 inode。大量小文件（比如邮件队列、日志轮转碎片、容器临时层）会快速吃光 inode，而 df -h 完全不体现这点。
- 运行
df -i，重点关注IUse%列 —— 若达到 100%，就是它了 - 定位高 inode 占用目录：
find /var -xdev -type f | awk -F/ '{d=$1; for(i=2;i<=5;i++) {d=d"/"$i}; print d}' | sort | uniq -c | sort -nr | head -10 - 典型重灾区：
/var/spool/clientmqueue（sendmail 邮件队列）、/var/lib/docker/overlay2（Docker 小文件层）、/var/log/journal（二进制日志碎片） - 清理前先确认业务影响：比如删
/var/spool/clientmqueue/*前，确保没重要待发邮件；删 journal 日志可用journalctl --vacuum-size=100M
排查被进程占用的“僵尸文件”
文件已被 rm 删除，但仍有进程打开着它的文件描述符（fd），空间不会释放 —— df 显示已满，du 却统计不到，这是最让人困惑的场景。
- 查这类文件：
lsof +L1（只显示 link count 为 0 的已删文件）或lsof | grep deleted - 输出中会看到类似
nginx 1234 www-data 12w REG 253,0 2.1G 1234567 /var/log/nginx/access.log (deleted) - 对应进程要么重启（如
systemctl restart nginx），要么 kill 后重拉 —— 不要强行rm，那没用 - 注意：某些长期运行的服务（如 Java 应用、数据库）可能缓存日志句柄数天，需结合
lsof -p PID精准定位 fd
验证挂载点是否嵌套覆盖
当一个目录既是物理分区挂载点，又在挂载前存有数据，df 统计的是底层设备，du 统计的是挂载后可见路径 —— 两者严重不一致时，大概率是挂载点“盖住”了原数据。
- 运行
mount，看是否有类似/dev/sdb1 on /data type ext4，同时/data目录下原本就有文件 - 临时卸载验证：
umount /data && du -sh /data && mount /data—— 如果卸载后du突然暴增，说明原数据被挂载遮住了 - 这种情况不能直接删
/data下内容，得先umount，再清理底层残留，否则删的是空目录 - 常见于运维误操作：先建好
/data，再格式化新盘并挂载过去，忘了清空原目录
别跳过 df -h 和 df -i 的组合比对
很多工程师只跑一遍 df -h 就开始删日志，结果删完还是报错 —— 因为根本原因在 inode 或僵尸文件。这两个命令必须一起看，且要在同一挂载点下比对。
- 例如：
df -h /显示Use% = 85%，但df -i /显示IUse% = 100%→ 必须处理 inode - 又如：
df -h /var是 99%，但du -sh /var只有 60G → 大概率存在僵尸文件或挂载覆盖 -
du默认不跨文件系统，加-x参数才严格限制在同一挂载点内统计，避免误把其他挂载点内容算进来 - 真正可靠的排查顺序永远是：
df -h→df -i→lsof +L1→mount→ 最后才是du -shx *
真正麻烦的从来不是空间本身，而是“空间去哪儿了”这个判断过程 —— df 和 du 不一致、lsof 输出一堆看不懂的 fd、find 扫描卡住不动……这些信号都在提示你：别急着删，先让数据自己说话。
