ext4，為什麼 70k 文件需要 88 個塊

[root@xx]# cat -n create_extents.sh 
    1  #!/bin/bash
    2
    3  if [ $# -ne 2 ]
    4  then
    5          echo "$0 [filename] [size in kb]"
    6          exit 1
    7  fi
    8
    9  filename=$1
   10  size=$2
   11  i=0
   12
   13  while [ $i -lt $size ]
   14  do
   15          i=`expr $i + 7`
   16          echo -n "$i" | dd of=$1 bs=1024 seek=$i
   17  done

所以我做了

sudo ./create_extents.sh  /device3/test70 70

然後，我使用 debugfs “stat” 命令來檢查它，

索引節點：13 類型：正常模式：0644 標誌：0x80000

Generation: 2638566511    Version: 0x00000000:00000001
User:     0   Group:     0   Size: 71682
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 88
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x53292990:042e685c -- Wed Mar 19 01:22:24 2014
atime: 0x5329298f:edd4dc60 -- Wed Mar 19 01:22:23 2014
mtime: 0x53292990:042e685c -- Wed Mar 19 01:22:24 2014
crtime: 0x5329298f:edd4dc60 -- Wed Mar 19 01:22:23 2014
Size of extra inode fields: 28
EXTENTS:
(ETB0):33803, (1):33825, (3):33827, (5):33829, (7-8):33831-33832, (10):33834, (12):33836, (14-15):33838-33839, (17):33841
(END)

為什麼需要這麼多塊？而且這個地方很分散..？我的塊大小是 4k。我知道 ext4 努力保持一個文件的位置。

謝謝

“Blockcount”值i_blocks是struct ext2_inode. 這是在欄位中返回給stat系統呼叫st_blocks的值。由於歷史原因，該欄位的單位是 512 字節塊——這是早期 Unix 文件系統上的文件系統塊大小，但現在它只是一個任意單位。您可以看到值的遞增和遞減僅取決於fs/stat.c.

stat /device3/test70您可以通過執行(“Blocks: 88”)看到相同的值。

該文件實際上包含 18 個塊，正如預期的那樣，塊大小為 4kB（文件長 71682 字節，不稀疏，17 × 4096 < 71682 ≤ 18 × 4096）。

令人驚訝的是，512 字節塊的數量是 88，而不是 141（因為 140 × 512 < 71682 ≤ 141 × 512）或 144（即 18 × 4096/512）。原因與fs/stat.c我上面連結的計算有關。您的腳本通過反複查找結束來創建此文件，並且對於i_blocks欄位計算，該文件是稀疏的 - 有整個 512 字節的塊從未寫入，因此不計入i_blocks. （但是，沒有任何儲存塊被完全搜尋過去，因此該文件實際上並不稀疏。）

如果您複製該文件，您將看到該副本有 144 個這樣的塊，如預期的那樣（請注意，您需要執行cp --sparse=never，因為 GNUcp試圖變得聰明並在它看到大量零時進行搜尋）。

至於範圍的數量，通過連續搜尋結束的方式創建文件並不是文件系統傾向於優化的情況。我認為文件系統驅動程序中的啟發式首先決定您正在創建一個小文件，因此首先要一次保留一個塊的空間；稍後，當文件增長時，啟發式開始一次保留多個塊。如果您創建一個更大的文件，您應該會看到越來越大的範圍。但我對 ext4 的了解不夠詳細，無法確定。

引用自：https://unix.stackexchange.com/questions/120323