服务器一直提示“磁盘已满”，但磁盘空间仍然充足？可能是inode用尽

df（Linux/Unix下查看文件系统磁盘空间使用情况的命令）一看还有两成空间，可上传文件就报No space left on device，日志也写不进去，重启服务照样报同样的错。这种矛盾状态最容易被误判成磁盘真满了，于是去删大文件，删掉几个G之后再看df，可用空间确实多了，可写文件还是失败。真正被用尽的往往不是容量，而是inode，也就是文件系统给每个文件准备的编号位。df默认只报容量，不报编号，这就是看着有空间却写不进去的原因，也是这套排查最容易走岔的地方。很多人第一反应是看日志占了多大，删掉之后df确实松了，可写文件照样失败。

判断只要一个命令，df -i，看IUse%那一列，不用装额外的工具。容量那一列还很宽裕、IUse%已经顶到一百，结论就定了，跟空间大小没有关系。这时候再去删大文件只是白费力气，删掉几个大文件也就腾出几个inode，对几十万的缺口没有意义。

inode的数量在文件系统创建那一刻就定死了，格式化时按容量比例分配，之后不能动态增加。一个文件占一个inode，一个目录也占一个，文件大小完全不影响这件事。所以几十万个零字节文件和一张几十G的镜像，在inode这件事上权重是一样的。有的文件系统支持在扩容时一并增加inode，前提是当初格式化留了余量，这个余量在建库时看不出来。

这也解释了为什么du帮不上忙。du统计的是文件占用的块，一堆零字节的小文件加起来可能只有几十兆，却能把几十万个inode吃光，du看不出异常，df也看不出异常，只有df -i能看出来。

堆积的来源很集中：PHP的session文件、程序自己写的临时文件、没清理的邮件队列、频繁生成又不删的缓存碎片。这几类共同点是小而多，单个都不起眼。想定位到具体目录，按文件夹统计文件数比看容量有效，用ls -U | wc -l挨个目录数一遍，数字异常的那个就是源头。

清理能救急，从源头控制才算解决。session目录配上定期回收，临时目录加清理任务，比出了问题再找要省事，也避免下一次同样的告警。

清完再跑一次df -i确认IUse%真的降下来，同时观察几天，看增长曲线是不是还在往上走。如果清完很快又满，说明产生速度超过了预期，要去查是哪个程序在不停建小文件，而不是继续清。把每次清理后的inode数记下来，下次有对照，也能算出增长速度有多快。