因为前期规划不完善和运维工作中的不细心，我们会碰到inode耗尽的情况。症状就是用df查看明明还有硬盘空闲空间，但系统却提示磁盘空间不足。

故障重现

为了直观的看到效果，这里拿虚拟机添加一块1G的磁盘来实验，格式化后，共有256个inode

图中能看到只剩下245个inode了，此时我执行如下命令串

for i in {1..246};do touch $i;done

生成246个文件，如图：

刚好在touch第246个文件的时候，系统提示"touch: cannot touch `246': No space left on device"

故障原因

故障原因很明显，inode号被用完了，为什么被用完了，因为文件数量过多。在生产环境有的业务类型本来就有很多小文件，这是不可避免的。但还有一个会生成很多小文件情况——cron
由于Linux在执行cron时，会将cron执行脚本中的output和warning信息，都会以邮件的形式发送Cron所有者， 而由于服务器上的sendmail或postfix没有正常运行， 导致邮件发送不成功，全部小文件堆积在了/var/spool/postfix/maildrop目录下面，而且没有自动清理转换的机制，经历较长时间后，此目录已堆积了大量的文件。

故障解决

对于业务需要本来就有很多小文件而耗尽inode(/data/jpg/下全是小图片)，这种情况，有一个变通的方法解决，不格盘获取大量inodes
先dd出一个img文件 dd if=/dev/zero of=/root/disk.img count=256 bs=1024KB （因为是实验，所以count设的很小）
然后格式化这个文件 mkfs.ext2 -b 1024 -I 128 /root/disk.img
其中“-b”和“-I”块大小和inode大小设为系统能接受的最小值以获取更多的inodes数量。
此时先把/data/jpg目录下的全部文件转移到同分区的另外一个目录
mv /data/jpg/* /data/pic/
然后把刚刚dd出来的img文件挂载到/data/jpg目录
mount -o loop /root/disk.img /data/jpg
最后把/data/pic目录里的所有文件移动到/data/jpg目录下。

面对这种问题，更好的办法是提前规划，针对业务需求在上线前就准备好使用reriserfs等会自动动态调整inodes的文件系统来面对inodes的骤增。