stat命令如何計算文件的塊？

Question

我想知道stat命令如何計算文件的塊。我讀了 article，它說：

值的st_blocks給出了512字節的塊中的文件的大小。 （這可能小於st_size/512，例如，當文件有空洞時。）值st_blksize爲高效的文件系統I/O提供「首選」塊大小。 （以較小的塊寫入文件可能導致讀取 - 修改 - 重寫效率低下。）

但我無法在我的測試中驗證它。

我的文件系統是ext3。

的dumpe2fs -h的/ dev/sda3上顯示：

... 
First block: 0 
Block size: 4096 
Fragment size: 4096 
... 

然後我跑

kent@KentT60:~/Desktop$ stat Email 
File: `Email' 
Size: 965 Blocks: 8 IO Block: 4096 regular file 
Device: 80ah/2058d Inode: 746095 Links: 1 
Access: (0644/-rw-r--r--) Uid: (1000/ kent) Gid: (1000/ kent) 
Access: 2009-08-11 21:36:36.000000000 +0200 
Modify: 2009-08-11 21:36:35.000000000 +0200 
Change: 2009-08-11 21:36:35.000000000 +0200 

如果此塊是指：有多少塊512字節，這個數字應該是2不8.我認爲，文件系統（io塊）的塊大小是4k。如果fs將得到文件Email，它將從磁盤取得最小4k（8 x 512字節塊），這意味着965/512 + 6 = 8。我不確定猜測是否正確。

另一個測試：

kent@KentT60:~/Desktop$ stat wxPython-demo-2.8.10.1.tar.bz2 
File: `wxPython-demo-2.8.10.1.tar.bz2' 
Size: 3605257 Blocks: 7056 IO Block: 4096 regular file 
Device: 80ah/2058d Inode: 746210 Links: 1 
Access: (0644/-rw-r--r--) Uid: (1000/ kent) Gid: (1000/ kent) 
Access: 2009-08-12 21:45:45.000000000 +0200 
Modify: 2009-08-12 21:43:46.000000000 +0200 
Change: 2009-08-12 21:43:46.000000000 +0200 


3605257/512=7041.xx = 7042 

按照上述我的猜測，這將是7042 + 6 = 7048但stat結果顯示7056

而在http://www.computerhope.com/unix/stat.htm從互聯網的另一個例子。我在這裏複製頁面底部的示例：

File: `index.htm' 
Size: 17137 Blocks: 40 IO Block: 8192 regular file 
Device: 8h/8d Inode: 23161443 Links: 1 
Access: (0644/-rw-r--r--) Uid: (17433/comphope) Gid: (32/ www) 
Access: 2007-04-03 09:20:18.000000000 -0600 
Modify: 2007-04-01 23:13:05.000000000 -0600 
Change: 2007-04-02 16:36:21.000000000 -0600 

在此示例中，FS塊大小爲8k。我想塊的數量應該是16xN，但它是40.迷路了...

任何人都可以解釋，stat是如何計算Blocks的？

謝謝！

Answer 1

stat命令行工具使用stat/fstat等函數，它們返回stat結構中的數據。該stat結構返回的st_blocks構件：

大小的物理塊的總數量實際上512個字節分配在磁盤上。該字段未針對塊特殊或字符特殊文件定義。

因此，對於您的「電子郵件」示例，大小爲965且塊數爲8，表示8 * 512 = 4096字節在物理上分配到磁盤上。不是2的原因是磁盤上的文件系統沒有以512爲單位分配空間，顯然以4096爲單位分配它們（並且分配的單位可能因文件大小和文件系統的複雜程度而異），例如ZFS支持不同的）

同樣，對於wxPython示例，它表示在磁盤上物理分配了7056 * 512字節或3612672字節。你明白了。

IO塊大小是「關於I/O操作'最佳'單元大小的暗示」 - 它通常是物理磁盤上的分配單位。不要混淆IO塊和stat用來指示物理大小的塊;物理大小的塊總是512字節。

更新基於評論：

就像我說的，st_blocks是操作系統如何指示多少空間可用於磁盤上的文件。磁盤上的實際分配單位是文件系統的選擇。例如，由於分配塊的方式，ZFS可以擁有可變大小的分配塊：，即使在相同的文件中：文件開始時具有較小的塊大小，並且塊大小持續增加，直到達到特定點。如果文件稍後被截斷，它可能會保留舊的塊大小。所以根據文件的歷史記錄，它可以有多個可能的塊大小。因此，給定文件大小並不總是顯而易見的，爲什麼它有一個特定的物理尺寸。

具體的例子：在我的Solaris系統，具有ZFS文件系統，我可以創造一個很短的文件：

$ echo foo > test 
$ stat test 
    Size: 4    Blocks: 2   IO Block: 512 regular file 
(irrelevant details omitted) 

OK，小文件，2塊物理磁盤使用情況是1024這個文件。

$ dd if=/dev/zero of=test2 bs=8192 count=4 
$ stat test2 
    Size: 32768   Blocks: 65   IO Block: 32768 regular file 

好的，現在我們看到物理磁盤使用率爲32.5K，IO塊大小爲32K。然後我就複製到test3，並在編輯器截斷該test3文件：

$ cp test2 test3 
$ joe -hex test3 
$ stat test3 
    Size: 4    Blocks: 65   IO Block: 32768 regular file 

現在好了，這裏的4個字節中有一個文件 - 就像test - 但它的使用32.5K物理磁盤上，因爲ZFS文件系統分配空間的方式。隨着文件變大，塊大小會增加，但當文件變小時塊大小不會減小。 （是的，這可能會導致大量浪費的空間，這取決於您在ZFS上執行的文件和文件操作類型，這就是爲什麼它允許您在每個文件系統基礎上設置最大塊大小並動態更改它的原因。）

希望您現在應該明白，文件大小和物理磁盤使用率之間不一定有簡單的關係。即使在上面，也不清楚爲什麼需要32.5K字節來存儲大小正好爲32K的文件 - 看起來ZFS通常需要額外的512個字節來存儲自己的額外存儲空間。也許它使用的是存儲校驗和，引用計數，事務狀態 - 文件系統簿記。通過在指定的物理文件大小中包含這些附加內容，看起來ZFS似乎不會誤導用戶關於文件的物理成本。這並不意味着在不知道底層文件系統實現的詳細信息的情況下對計算進行逆向工程就顯得微不足道了。