本文第一部分介紹經典檔案系統ext3的塊儲存，第二部分介紹一個NoSQL分散式儲存系統的塊儲存。

    ext系列檔案系統是linux的土著檔案系統，歷經4個版本，最新是ext4，在linux 2.6.28核心正式引入，目前比較新的linux發行版都已經把ext4做為預設檔案系統。下面先看看ext3的資料塊儲存結構，而ext4是對ext3的繼承與優化，核心結構基本類似，同時也對ext3的提供向下相容，後面再討論它們的區別。

    首先看看ext3的檔案系統的結構圖：

    ext3整體結構還是清晰明瞭：

    1）引導塊，主要是給系統引導的時候用的，包括512位元組的MBR和64位元組的分割槽表，餘下的是保留區間。

    2）塊組部分，則是由ext3檔案系統管理的區域，塊組編號從0開始。每個塊組都包含data block bitmap、inode bitmap、inode table以及data block table（少數塊組會有super block和gdt（gdt包含了檔案系統所有塊組的塊描述符），但是檔案系統一般只使用塊組0的super block和gdt，其他塊組的super block和gdt只是在一些時間點上進行備份，以防塊組0崩潰了可以恢復到一個比較一致性的狀態）。

    塊大小、每個塊組包含的塊數目、塊組內inode table和data block table都是在建立檔案系統的時候就設定好了。所以在檔案系統的使用過程中根據給定的inode number（inode number從0開始編號，一直單調遞增1），可以快速定位到所屬的塊組和在該塊組的inode table裡面的偏移量。同理給定block number（block number也是從0開始編號，一直單調遞增1），可以快速定位到所屬的塊組和在該塊組中data block table的偏移量。可以看到這種線性的組織方式是靜態的，從檔案系統建立那一刻就分配好了（不過由於ext3有一些保留塊，這些保留塊也為檔案系統的resize提供了一定支援，主要是為了儲存更多的gd）。

    下面再看看ext3的資料塊索引：

    ext3的inode中有一個重要的資料成員i_block（其實上面這個圖如果橫著展開的話，其實是一顆樹型結構），是一個包含15個32位整數的陣列，其中前12個元素直接儲存的儲存檔案資料的block的block number；第13個元素儲存的block number指向的block裡面儲存的是block number陣列，而非檔案資料，簡稱一次間接索引。同理，第14個元素儲存的二次間接索引，第15個元素儲存的是三次間接索引，此機制保證了ext3最大支援的單個檔案大小為4TB多一點（假設block size是4K，那麼最大的檔案大小=4K*12 + 4K/4*4K + 4K/4*4K/4*4K+4K/4*4K/4*4K/4*4K ~= 4TB，但是實際上由於ext3實現的限制，為了使得每個檔案包含的磁碟扇區數不超過2^32個，所以在block size為4K的情況下，ext3的最大檔案大小實際上只有2TB）。如果檔案系統的block size是4K，那麼只要不大於48K，都只使用前12個元素，否則就會用到後面的間接索引。試想如果要訪問一個2G檔案的最後4KB，那麼將要經歷二次索引和一次索引，如果包含索引的資料塊不在pagecache中，那麼將發生多次IO讀，效率有點低。

    在ext4中，ext4的inode依然保留了i_block這種結構，而且提供向前相容，同時也提供了更具彈性的extend分配方式（最多有4個extend，但是extend也可以是多級樹形索引組織，一個extend由邏輯塊號、塊數和物理塊號標識），只是extend的儲存是重用這個i_block的儲存空間的，也就是ext4相容兩種分配方式。對比ext3基於三級間接索引的分配機制和ext4的extend分配機制，首先在元資料規模上就有很大區別。試想如果一個4G的大檔案，且檔案系統block size是4K，則檔案需要100w個block儲存，也就是需要儲存100w個block number，每個block number是4個位元組，那麼就至少需要4M的元資料了，這個還不包括一次和二次間接索引需要的資料塊。其實問題很簡單，在這種分配方式下的索引資料的熵值永遠>=4/4K，即千分之一。如果採用extend分配方式，元資料規模將大大降低，因為一個extend可以標識很多塊連續的資料塊。

    以上兩個圖的結構基本上是ext3的on disk結構（也就是物理磁碟上實實在在儲存的資訊），至於in memory的結構基本上跟這個on disk的結構一一對映，只是做了少許封裝。個人認為ext3/4的精髓在於分組管理和bitmap應用（這裡暫時不討論ext3/4的journal部分，因為jbd嚴格上來說不屬於具體的檔案系統，而是一個通用的檔案系統日誌管理模組，jbd本身的複雜度一點不比ext3簡單），一般檔案的資料都優先儲存在同一個塊組裡面，這樣就帶來了IO的聚集特徵，對效能有好處。其次簡單的bitmap既節省了元資料的規模計算也比較簡單。由於簡單的物理結構，所以必定帶來不怎麼高的效能，幸好inode cache和dentry cache和pagecache的充分利用使得ext3在一般情況下效能還可以。

    使用ext3檔案系統往往有這樣一種糾結：該檔案系統對小檔案的物理儲存本身是高效率的，從i_block的構造看出來，但是小檔案帶來了大量索引開銷（inode儲存和查詢）卻起到了相反的作用；物理儲存本身對大檔案卻是低效率的，因為要經過多次索引，且資料塊不連續的概率很大，但是使用大檔案索引開銷卻比較低。從實際的應用角度上看，大量小檔案的應用是真正的效能殺手，特別是32位系統以前經常會由於大量小檔案而消耗了大量low memory，導致核心由於低記憶體不足而產生oom-killer現象，所以一般都對小檔案進行封裝成大檔案，然後動態對映大檔案訪問，只要記憶體足夠大，間接索引塊的pagecache命中率還是很高的。

    ext4是對ext3的繼承和優化改進，主要打破了ext3在磁碟容量、檔案大小、子目錄數等等的硬限制。但是為了向前相容，核心的ondisk資料結構基本沒什麼大改，主要是在結構尾部增加了一些細化計量和加速欄位，ext4在功能演算法和in memory結構組織方面有比較大的改進。

像ext3/4這種支援POSIX標準介面的檔案系統，基本都實現在核心態，即位於核心中VFS的下一層（除非採用FUSE那樣的機制，能在使用者態實現）。這種經典的檔案系統往往由於考慮太多功能需求和介面標準，無法應對網際網路海量檔案儲存在效能和伸縮上的要求，因此也就湧現了像google的GFS和hadoop的HDFS這樣的基於使用者態的分散式檔案儲存系統，其實這類檔案系統應該稱為No-POSIX檔案系統，因為No-SQL系統其實是相對於SQL-based的DBMS而言的（後續都稱No-Posix）。下面介紹一種應用於網際網路的No-Posix分散式檔案系統的塊儲存實現（由於本主題只分析塊儲存實現，所以對於其他層次的東西暫時忽略）。

        首先看看該檔案系統是如何對硬碟進行管理的，其on disk結構圖如下：

        看這個圖，跟一般的檔案系統（比如ext3）對硬碟的管理有點相似，但它是直接在塊裝置檔案（比如/dev/sdb）上構建的，在使用者態通過libc的IO函式讀寫塊裝置檔案來儲存檔案資料（並沒有在塊裝置上建立任何核心中已經註冊的檔案系統）。除了前面4K的disk head是為了相容系統對硬碟引導塊的需求以外（基本無用），剩下的空間被被劃分為多個等同大小的CHUNK塊。每個CHUNK塊裡面主要由binlog section和data section構成。binlog section其實是存放了大量的inode變更記錄，每次inode的增加、刪除、修改都會相應在binlog中寫入一條記錄（因此binlog section的大小也限制了inode的個數）。但是這裡的inode其實並不是像ext3檔案系統中的檔案inode，這裡的inode只是描述CHUNK裡面一片檔案資料的元資料所形成的inode（實際這樣一個inode的空間只有二三十個位元組，比ext3的128位元組的inode相差甚遠）。而data section則是儲存真正檔案資料片的區域。這裡可以看到，CHUNK裡面是沒有專門的像ext3那樣的inode table區域的，因為inode只有in memory形態（機器故障恢復或者程序重啟，都需要從binlog中恢復記憶體中的inode表）。

        CHUNK是整個檔案系統的基本儲存空間分配單元，大量位於不同機器上不同硬碟的CHUNK構成了整個檔案系統可用的儲存空間，而CHUNK之間可以互相配對，形成應用態的Raid1儲存。（一個使用者角度的檔案實際上被劃分為多個數據片，一般按照某個定長來劃分，這些資料片可以儲存在不同的CHUNK上，使用者讀取檔案的時候，通過一個檔案索引層找出這些資料片所在的CHUNK，然後再訪問這些CHUNK來讀取資料）

        雖然一個CHUNK的on disk結構很簡單，但是其in memory結構相比稍微複雜一點點，也只有這樣才能在效能上有提升，否則什麼都跟硬碟對映起來，兩者的資料一致性同步的代價是挺高的。下面看一個CHUNK的in memory結構：

        一個CHUNK由一個chunk inode來描述（實際上chunk inode也只有in memory形態）。chunk inode主要使用inode hash table來管理屬於本CHUNK的inode。簡單的inode構造和hash table實現也註定了它不是傳統意義上的檔案系統，平坦而無序，更接近key-value式儲存。每個chunk inode有一個offset變量表明其data section的已使用區間位置（由於每個CHUNK大小一樣，所以offset大小也決定了CHUNK剩餘空間的大小，從而可以利用這個指標來進行負載均衡，使得每個CHUNK的剩餘空間都差不多）。而資料片的inode主要是儲存了一個offset和length，分別表示該資料片在CHUNK裡的偏移量和資料片長度，理論上說這樣的訪問效率會比較高。每個CHUNK都是以append的方式在不斷增長，即使資料片刪除了，也不會立即回收空間，只是對inode做一個標誌。

如果很少刪除，那麼這種方式其實是挺好的，但是如果刪除很頻繁，那麼每個CHUNK已使用區間會有很多空洞而不能重複利用，這是一個主要弊端。解決方法其實有很多，一個是修改演算法使得inode和空洞能重用，另一個方法就是定期對整個CHUNK進行pack操作（此時需要暫時遮蔽對該CHUNK的讀寫訪問），使得空洞全部轉移到尾部的未使用區間，而且重新整理binlog section。當然，前面說到這裡的CHUNK裡面的資料片inode並不是代表真正的檔案，所以該分散式檔案系統還需要有一層分散式的索引層（索引層是否分散式並不重要，像GFS和HDFS則是集中式的，由master或name node來管理）來表示真正的使用者角度的檔案，這個索引層本身採用的是典型的key-value儲存。相對來說，資料量至少降低2-3個數量級。

對比傳統的檔案系統（比如ext3），這類No-Posix的分散式檔案系統，其實是大大簡化了底層的儲存塊分配與讀寫機制，同時在元資料上也儘量節省，只要夠用就行（更多的擴充套件性放到了更高的層次去解決）。其次，在資料一致性和資料恢復方面，在儲存層這一級別也是比較輕量級的，起碼沒有像jbd這樣重的機制。再次，這類No-Posix的分散式檔案系統通過在應用層次的N份映象儲存，來規避單機可靠性較低，以得到較高的整體可用性。傳統檔案系統更多的是考慮到磁碟空間的利用率，比如如何重複利用磁碟空間（比如檔案的覆蓋寫），如何對檔案的併發讀寫進行同步互斥等等，這些在No-Posix的分散式檔案系統裡面基本都弱化了，往往採用的是append的方式來提升寫速度，通過多CHUNK的併發讀來提升讀速度，通過上層限制併發寫來維護資料一致性等等。最後，對於這種No-Posix的分散式檔案系統而言，其實索引的組織並不是最關鍵的，往往簡單的雜湊分佈已經足夠，通過在多個機器間分攤計算量來達到較好的效能，而傳統的單機檔案系統往往需要考慮較複雜的索引組織結構來提升效能（比如遍歷目錄檔案），因為單機容易出現效能瓶頸。

當然，對於No-Posix的分散式檔案系統來說，其實也是可以在上層實現有限的Posix介面，只是這種實現往往犧牲了效率。對於傳統單機檔案系統，比如btrfs，zfs等已經達到了一個非常高的水平。而像ceph這類比較激進的分散式檔案系統，既能實現Posix介面，又能高效利用btrfs等作為儲存節點的檔案系統，也許是一個比較好的結合點。