EXT4 中 inode 數量增加的缺點
我目前正在使用
backintime我的文件系統的“快照”。它與它的相似之處rsnapshot在於它對未更改的文件進行硬連結。EXT4我最近在我的文件系統上用完了 inode 。df -hi顯示我使用了 940 萬個 inode。目前目錄數量乘以快照數量加上目前文件數量的粗略計算表明，我實際上可能使用了 940 萬個 inode。據我了解，
EXT4文件系統可以支持大約 2^32 個 inode。我正在考慮重新格式化分區以使用所有 40 億左右的 inode，但我擔心這是一個壞主意。在文件系統中有這麼多 inode 有什麼缺點EXT4？對於這樣的應用程序，是否有更好的文件系統選擇？
這真是個壞主意。每個 inode 消耗 256 個字節（可以配置為 128 個）。因此，只有 inode 會消耗 1TiB 的空間。
其他文件系統（如 btrfs）可以動態創建 inode。請改用其中之一。
我真的不能強調這一點，不要創建一大堆 inode！
首先，您的
fsck執行時間可以成倍地延長，儘管其中一些問題已在 ext4 中得到解決。更重要的是，inode 並不是唯一限製文件數量的因素，可能不可能使用所有這些 inode。這不僅在實踐上說，而且在技術上實際上可能是不可能的。mkfs 手冊頁的摘錄，
-i bytes-per-inode 指定字節/inode 比率。mke2fs 為磁碟上每字節空間的每個字節創建一個 inode。每個 inode 的字節數比率越大，創建的 inode 就越少。該值通常不應小於文件系統的塊大小，因為在這種情況下，將產生比以往更多的 inode。請注意，文件系統創建後無法擴展 inode 的數量，因此請謹慎確定此參數的正確值。
在創建 OP 的新文件系統時，實際上，OP 應該開始計算每個 inode 的最大字節數 = blocksize …. 對於稍後閱讀此內容的每個人來說，OP 都有一個非常不尋常的情況一個巨大的數字文件。