為什麼 67108864 是每個 inode 的最大字節數比？為什麼有最大值？
為純大型影片文件格式化磁碟，我計算了我認為合適的每 inode 字節值，以最大化可用磁碟空間。
然而，我受到了歡迎：
mkfs.ext4: invalid inode ratio [RATIO] (min 1024/max 67108864)我假設最小值是從理論上可以使用的東西中得出的——沒有比以往任何時候都可以使用的更多的 inode。
但最大值從何而來？
mkfs不知道我將放在它創建的文件系統上的文件大小 - 所以除非是這樣，否則{disk size} - {1 inode size}我不明白為什麼我們有一個最大值，更不用說一個低至 67MB 的文件了。
由於文件系統的建構方式。這有點混亂，預設情況下，您甚至不能將比率降至 1/64 MB。
從kernel.org 上的 Ext4 磁碟佈局文件中，我們看到文件系統內部與塊大小（預設為 4 kB）相關聯，它控制塊組的大小和塊組中的 inode 數量. 塊組具有該組中塊的一個塊大小的點陣圖，以及至少一個 inode 塊。
由於點陣圖，最大塊組大小為
8 blocks * block size in bytes，因此在具有 4 kB 塊的 FS 上，塊組大小為 32768 個塊或 128 MB。inode 至少佔用一個塊，因此對於 4 kB 塊，每 128 MB 至少(4096 B/block) / (256 B/inode) = 16 inodes/block或 16 個 inode，或每 8 MB 1 個 inode。對於 256 B/inode，即 256 B / 8 MB，或每 32 kB 1 個字節，或約 0,003% 的 inode 總大小。
減少 inode 的數量無濟於事，您只會得到一個部分填充的 inode 塊。此外，inode 的大小也並不重要，因為分配是按塊完成的。塊組大小才是元數據的真正限制。
增加塊大小會有所幫助，理論上，最大塊組大小會以塊大小的平方增加（除了它似乎上限略低於 64k 塊/組）。但是您不能使用大於系統頁面大小的塊大小，因此在 x86 上，您只能使用 4 kB 塊。
但是，有一個正是您想要的
bigalloc功能：對於大多數包含大文件的文件系統，希望能夠以多個塊為單位分配磁碟塊，以減少碎片和元數據成本。bigalloc 特性正好提供了這種能力。
管理員可以在 mkfs 時間設置一個塊群大小（儲存在 superblock 的 s_log_cluster_size 欄位中）；從那時起，塊點陣圖跟踪集群，而不是單個塊。這意味著塊組的大小可以是幾 GB（而不僅僅是 128MiB）；然而，最小分配單元變成了一個群，而不是一個塊，即使對於目錄也是如此。
您可以使用 啟用它
mkfs.ext4 -Obigalloc，並使用 設置集群大小-C<bytes>，但mkfs請注意：Warning: the bigalloc feature is still under development See https://ext4.wiki.kernel.org/index.php/Bigalloc for more information
ext4在該頁面和手冊頁上提到了與延遲分配相結合的問題，並且Bigalloc wiki 頁面上也出現了*“巨大風險”一詞。*
-i這些都與該選項設置的 64 MB / inode 限制無關。它似乎只是在介面級別設置的任意限制。inode 的數量也可以直接使用該-N選項設置，並且在使用時，沒有檢查。此外，上限是基於文件系統的最大塊大小，而不是實際選擇作為結構限制的塊大小。由於 64k 塊/組的限制，如果
bigalloc沒有 64 MB / inode 的比率所暗示的那樣少的 inode，則無法獲得盡可能少的 inode，並且bigalloc可以將 inode 的數量設置得比它低得多。