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耗尽的情况，在业务恢复的紧急时候，还是很抓狂的。
本文出自 “记忆碎片” 博客，请务必保留此出处http://weikle.blog.51cto.com/3324327/1617091
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
