前言

最近在tune ext4 的格式化速度，發現ext4 有 flex_bg 這個 feature 可以用，就開起來測看看。關於 flex_bg 的詳細內容可以參考 ref

概略來說就是將幾個block groups 組成一個 flex_bg
它會將每個 flex_bg 的 group 0 之後的 groups 的 DB bitmap, inode bitmap, inode table
存放到 group 0 統一管理(放不下的時候會放到下一個group)
存放的時候每個 DB bitmap, inode bitmap 都會佔 1 個 block, inode table 會佔 8 個 block
所以DB bitmap, inode bitmap, inode table 之間在開始存放的時候都隔 $GRUUP_SIZE 個blocks (-G $GRUUP_SIZE帶入)

測試

flex_bg 預設的 group size 是 16，使用2的冪次遞增group size來測試的時候一開始一切看
起來都很美好，format 時間隨著group size 增加而下降。一直到 group size 指定為
8192的時候忽然發現 format time 暴增...



這真的蠻奇怪的...網路上也找不到相關的討論。於是只好自己去看 e2fsprogs 裡面關於mke2fs這一段的實作在幹嘛。

結論

首先 在 block size 4KB 下 ext4 管理用的 bitmap 最多 可以 mapping 32K個 block (bitmap佔1個block 32k bits)
所以 blocks per group 最多就是 32768 (可以調小 調小有可能會造成mke2fs 在 -G4096 的時候變慢 後面說明)
以 8K 的 group size 配置的時候，這些metadata(DB bitmap, inode bitmap, inode table)的初始擺放位置
分別是第 1025, 9217, 17409 個 block (中間都間隔 8192 個 block)

這在放置到第 1919 個 group 的 metadata 的時候會發生一個現象





可以看到在配置第 1918 個 group 的 inode table 時即將超出 group 0 的邊界了(32768 blocks per group)

所以在配置地 1919 個 group 的 inode table 時 mke2fs 的實作方法會回頭找 free block 來
存放。這時候找到的是第 2945 個 block(當然如果 group 0 中都沒有 free block 放
metadata 的時候 會開始往 group 1 放不過 mke2fs 的策略看來是 group 0 還有空間就先用
group 0 ... 就算最後一定不夠用如果它是接著往 group 2 放 inode table 的話 就不會有現在的問題了...)
這就造成原本理想上算好間隔分散存放的 metadata 開始交錯配置了。在找free block的時候
原本都是馬上返回下一個free block 的 function call (flexbg_offset)在開始交錯配置以後
都要再做一些 search 才能找到下一個可以用的blockprofile
整個 mke2fs 過程花最多時間也是在 flexbg_offset 這個 function call
(對 1TB 硬碟format 整個 format 過程 總共花 126 秒 其中有121 秒花在 flexbg_offset 的處理)
所以在 GROUP_SIZE 是 8192 的時候會因為這些 metadata 在 group 0 裡面配置的時候容易發生交錯放置的情況
以至於 mke2fs 在搜尋下一個可以放metadata 的 block 的時候 比起其他的 GROUP_SIZE 花比較多的 overhead。

另外 

如果在 -G 8192 的時候加上 -b 8192 的 option (指定 block size 成 8K)->
則 -G 8192 就會變得跟 -G 4096 速度差不多。這是因為 block size 變 8K -> blocks per group 變 64K
(其實有少一些零頭 實際上是 65528個，bitmap 可以 mapping 的 block 數 變 64K )
則 inode table 配置的時候 不會很快遇到 group block 邊界的問題 就比較不會發生和 DB bitmap 或 inode bitmap 交錯配置的情況