ufs檔案系統下inode耗盡導致業務進程重啟失敗

標籤：solaris10 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

ufs檔案系統下inode耗盡導致業務進程重啟失敗