磁盘明明有空位，写文件却报 No space left？多半是 inode 用完了

df -h 看着还有空间，touch 一个新文件却报 No space left on device，或者服务写日志、建缓存突然失败。这种情况多半不是磁盘满了，而是 inode 用完了。

先说清两个概念：磁盘空间是按块算的，inode 是按文件个数算的。每个文件、每个目录都要占一个 inode，文件系统建好时 inode 总数就定死了。小文件再多也不怎么占空间，但每个都要吃一个 inode，攒到一定数量，空间还剩不少，inode 先耗尽，新文件就建不出来了。

先诊断：df -h 正常时再跑 df -i，看 IUse% 那一列，哪个挂载点到了 100% 就是它。然后找是谁吃掉的：du --inodes -s /var/* 这类命令按目录数 inode，或者 find /var -xdev -type f | wc -l 看文件数。常见的几处：/var/spool 里的邮件队列、PHP session 目录、没配好 logrotate 的日志目录、/tmp 下长年没清的会话文件、Docker 的 overlay 层里大量小文件。先定位到目录，再看里面是什么，别一上来就 rm -rf。

清理时注意两点：一是先确认文件能不能删，会话、队列、缓存文件删了一般能重建，但业务数据不行；二是删完后如果服务还占着已删文件的句柄，inode 不会立即释放，重启一下相关服务才彻底。删完再跑 df -i 确认 IUse% 降下来了。

预防比救火省事：监控别只看磁盘用量百分比，把 inode 使用率也加进去，超过 80% 就告警；/tmp 和 session 目录配好定时清理（systemd-tmpfiles 或 cron），日志配好 logrotate 按大小和时间轮转。空间和 inode 两条线都盯着，下次再报 No space left，先看 df -i 就能少走一半弯路。