上周客户报障，说他们的文件服务器传不上文件了，报错 disk quota exceeded，但又说磁盘空间应该是够的。我把 df -h 一拉，确实，/ 分区还剩 100 多 G，怎么看都够。

但报错很明确：No space left on device。我第一反应是配额（quota）？查了一下，没开配额。又怀疑是不是挂载点的问题，结果 df -i 一拉，真相出来了：/ 分区的 inode 使用率 100%，可用 inode 是 0。

inode 满了。空间还有 100G，但文件数到顶了。每个分区能建的文件数量是有限的，inode 就是文件系统的"户口本"，一个文件占一个 inode，户口本用完了，哪怕房子空着也住不进新人。

问题是：什么东西占了几百万个 inode？我让同事 find / -xdev -type f | wc -l 数一下，显示 380 多万个文件。正常一台文件服务器，几十万个文件顶天了，380 万明显不对劲。

顺着 inode 占用最多的目录查，du --inodes 一层层往下走，最后定位到 /var/spool/ 下面一个目录：是之前某个监控脚本写出来的临时文件，每个文件名带时间戳，一分钟写一个，写了大半年，攒了三百多万个没清理。

这脚本是哪个同事写的已经查不出来了，反正是某次调试留下的，忘了删。清理：把三个月前的临时文件全删了，删了大概 280 万个文件，inode 使用率降到 21%。删除的时候 rm 卡了很久——删几百万个小文件，rm 也是要一条条来的，等了十几分钟才好。

恢复之后，文件服务器马上能传文件了。同事说差点就要重装系统了，我说幸亏你没重装，重装也解决不了问题，数据还在，空间还在，就是 inode 满了而已。

这事之后我在监控里加了一条：inode 使用率超过 85% 就告警。空间告警大家都会配，inode 告警经常被忽略，但 inode 满了和磁盘满了一样致命，而且更难排查——因为 df -h 看着一切正常。

写下来给同行提个醒：遇到"空间明明够却写不进去"，先别急着怀疑配额和权限，df -i 看一眼，inode 满没满，一秒就知道。