ufs文件系统下inode耗尽导致业务进程重启失败

一次业务升级后，发现生产系统上的业务进程UPRG无法启动，日志里面报错：can not create UPRG.log，但是观察/logs目录剩余空间还有很多。尝试直接在/logs下touch文件也失败，也是报can not create file。

第一反应是/logs目录的权限是否被人误改了？但很快便发现目录权限正常。

第二反应是磁盘坏了，但想想磁盘是RAID1，不可能两个盘都坏了，而且系统日志里面没有任何磁盘报错。

第三反应是分区表坏了，但如果分区表坏了，应该cd都不能进去。

。。。

最后发现原来是inode耗尽了,用find+xargs狂删一堆日志文件后，业务进程成功启动了。

（以下参考http://blog.chinaunix.net/uid-119039-id-2802580.html）

inode数计算公式:
inode_number=文件系统大小/nbpi

文件系统大小(GB)       缺省的nbpi大小(byte)
≤1                    2048
1<fs≤2                4096
2<fs≤3                6144
3<fs≤1023 8192        8K
≥1024(即1T)           1M

我们/logs是64G，这么算下来inode总数是64*1024*1024/8=800万。

也就是说/logs目录下只能创建800多万个文件，而此生产机上新上的一个业务，将每个用户的日志都单独生成一个日志文件，因此导致小文件数目暴涨，在日志清理周期内就耗尽了inode，从而引发问题。

另外，感觉solaris的提示不够人性化，在这种情况下，报：can not create file，它完全可以报：

can not create file due to exhaustion of inode。即使是工作多年的运维，也很难遇到一次生产系统inode耗尽的情况，在业务恢复的紧急时候，还是很抓狂的。