【計算機基礎】：磁盤I/O那些事

引言

計算機硬件性能在過去十年間的發展普遍遵循摩爾定律，通用計算機的CPU主頻早已超過3GHz，內存也進入了普及DDR4的時代。然而傳統硬盤雖然在存儲容量上增長迅速，但是在讀寫性能上並無明顯提升，同時SSD硬盤價格高昂，不能在短時間內完全替代傳統硬盤。傳統磁盤的I/O讀寫速度成爲了計算機系統性能提高的瓶頸，制約了計算機整體性能的發展。

硬盤內部主要部件爲磁盤盤片、傳動手臂、讀寫磁頭和主軸馬達。實際數據都是寫在盤片上，讀寫主要是通過傳動手臂上的讀寫磁頭來完成。實際運行時，主軸讓磁盤盤片轉動，然後傳動手臂可伸展讓讀取頭在盤片上進行讀寫操作。

由於單一盤片容量有限，一般硬盤都有兩張以上的盤片，每個盤片有兩面，都可記錄信息，所以一張盤片對應着兩個磁頭。盤片被分爲許多扇形的區域，每個區域叫一個扇區，硬盤中每個扇區的大小固定爲512字節。盤片表面上以盤片中心爲圓心，不同半徑的同心圓稱爲磁道，不同盤片相同半徑的磁道所組成的圓柱稱爲柱面。磁道與柱面都是表示不同半徑的圓，在許多場合，磁道和柱面可以互換使用。

早期的硬盤每磁道扇區數相同，此時由磁盤基本參數可以計算出硬盤的容量：存儲容量=磁頭數*磁道（柱面）數*每道扇區數*每扇區字節數。 由於每磁道扇區數相同，外圈磁道半徑大，裏圈磁道半徑小，外圈和裏圈扇區面積自然會不一樣。同時，爲了更好的讀取數據，即使外圈扇區面積再大也只能和內圈扇區一樣存放相同的字節數（512字節）。這樣一來，外圈的記錄密度就要比內圈小，會浪費大量的存儲空間。

如今的硬盤都使用ZBR（Zoned Bit Recording，區位記錄）技術，盤片表面由裏向外劃分爲數個區域，不同區域的磁道扇區數目不同，同一區域內各磁道扇區數相同，盤片外圈區域磁道長扇區數目較多，內圈區域磁道短扇區數目較少，大體實現了等密度，從而獲得了更多的存儲空間。此時，由於每磁道扇區數各不相同，所以傳統的容量計算公式就不再適用。實際上如今的硬盤大多使用LBA（Logical Block Addressing）邏輯塊尋址模式，知道LBA後即可計算出硬盤容量。

1. 磁盤的關鍵因素

影響磁盤的關鍵因素是磁盤服務時間，即磁盤完成一個I/O請求所花費的時間，它由尋道時間、旋轉延遲和數據傳輸時間三部分構成。

1. 尋道時間

Tseek是指將讀寫磁頭移動至正確的磁道上所需要的時間。尋道時間越短，I/O操作越快，目前磁盤的平均尋道時間一般在3-15ms。

2. 旋轉延遲

Trotation是指盤片旋轉將請求數據所在的扇區移動到讀寫磁盤下方所需要的時間。旋轉延遲取決於磁盤轉速，通常用磁盤旋轉一週所需時間的1/2表示。比如：7200rpm的磁盤平均旋轉延遲大約爲60*1000/7200/2 = 4.17ms，而轉速爲15000rpm的磁盤其平均旋轉延遲爲2ms。

3. 數據傳輸時間

Ttransfer是指完成傳輸所請求的數據所需要的時間，它取決於數據傳輸率，其值等於數據大小除以數據傳輸率。目前IDE/ATA能達到133MB/s，SATA II可達到300MB/s的接口數據傳輸率，數據傳輸時間通常遠小於前兩部分消耗時間。簡單計算時可忽略。

機械硬盤的連續讀寫性能很好，但隨機讀寫性能很差，這主要是因爲磁頭移動到正確的磁道上需要時間，隨機讀寫時，磁頭需要不停的移動，時間都浪費在了磁頭尋址上，所以性能不高。

2. 磁盤的衡量指標

衡量磁盤的重要主要指標是IOPS和吞吐量。

1. IOPS

IOPS（Input/Output Per Second）即每秒的輸入輸出量（或讀寫次數），即指每秒內系統能處理的I/O請求數量。隨機讀寫頻繁的應用，如小文件存儲等，關注隨機讀寫性能，IOPS是關鍵衡量指標。可以推算出磁盤的IOPS = 1000ms / (Tseek + Trotation + Transfer)，如果忽略數據傳輸時間，理論上可以計算出隨機讀寫最大的IOPS。常見磁盤的隨機讀寫最大IOPS爲： - 7200rpm的磁盤 IOPS = 76 IOPS - 10000rpm的磁盤IOPS = 111 IOPS - 15000rpm的磁盤IOPS = 166 IOPS。

2. 吞吐量

吞吐量（Throughput），指單位時間內可以成功傳輸的數據數量。順序讀寫頻繁的應用，如視頻點播，關注連續讀寫性能、數據吞吐量是關鍵衡量指標。它主要取決於磁盤陣列的架構，通道的大小以及磁盤的個數。不同的磁盤陣列存在不同的架構，但他們都有自己的內部帶寬，一般情況下，內部帶寬都設計足夠充足，不會存在瓶頸。磁盤陣列與服務器之間的數據通道對吞吐量影響很大，比如一個2Gbps的光纖通道，其所能支撐的最大流量僅爲250MB/s。最後，當前面的瓶頸都不再存在時，硬盤越多的情況下吞吐量越大。

雖然15000rpm的磁盤計算出的理論最大IOPS僅爲166，但在實際運行環境中，實際磁盤的IOPS往往能夠突破200甚至更高。這其實就是在系統調用過程中，操作系統進行了一系列的優化。

3. 操作系統是如何操作硬盤的？

那麼操作系統是如何操作硬盤的呢？類似於網絡的分層結構， 對於磁盤的一次讀請求，首先經過虛擬文件系統層（VFS Layer），其次是具體的文件系統層（例如Ext2），接下來是Cache層（Page Cache Layer）、通用塊層（Generic Block Layer）、I/O調度層（I/O Scheduler Layer）、塊設備驅動層（Block Device Driver Layer），最後是物理塊設備層（Block Device Layer）。

第一層： 虛擬文件系統層（VFS Layer）

VFS（Virtual File System）虛擬文件系統是一種軟件機制，更確切的說扮演着文件系統管理者的角色，與它相關的數據結構只存在於物理內存當中。它的作用是：屏蔽下層具體文件系統操作的差異，爲上層的操作提供一個統一的接口。正是因爲有了這個層次，Linux中允許衆多不同的文件系統共存並且對文件的操作可以跨文件系統而執行。

VFS中包含着向物理文件系統轉換的一系列數據結構，如VFS超級塊、VFS的Inode、各種操作函數的轉換入口等。Linux中VFS依靠四個主要的數據結構來描述其結構信息，分別爲超級塊、索引結點、目錄項和文件對象。

1. 超級塊（Super Block）：超級塊對象表示一個文件系統。它存儲一個已安裝的文件系統的控制信息，包括文件系統名稱（比如Ext2）、文件系統的大小和狀態、塊設備的引用和元數據信息（比如空閒列表等等）。VFS超級塊存在於內存中，它在文件系統安裝時建立，並且在文件系統卸載時自動刪除。同時需要注意的是對於每個具體的文件系統來說，也有各自的超級塊，它們存放於磁盤。

2. 索引結點（Inode）：索引結點對象存儲了文件的相關元數據信息，例如：文件大小、設備標識符、用戶標識符、用戶組標識符等等。Inode分爲兩種：一種是VFS的Inode，一種是具體文件系統的Inode。前者在內存中，後者在磁盤中。所以每次其實是將磁盤中的Inode調進填充內存中的Inode，這樣纔是算使用了磁盤文件Inode。當創建一個文件的時候，就給文件分配了一個Inode。一個Inode只對應一個實際文件，一個文件也會只有一個Inode。

3. 目錄項（Dentry）：引入目錄項對象的概念主要是出於方便查找文件的目的。不同於前面的兩個對象，目錄項對象沒有對應的磁盤數據結構，只存在於內存中。一個路徑的各個組成部分，不管是目錄還是普通的文件，都是一個目錄項對象。如，在路徑/home/source/test.java中，目錄 /, home, source和文件 test.java都對應一個目錄項對象。VFS在查找的時候，根據一層一層的目錄項找到對應的每個目錄項的Inode，那麼沿着目錄項進行操作就可以找到最終的文件。

4. 文件對象（File）：文件對象描述的是進程已經打開的文件。因爲一個文件可以被多個進程打開，所以一個文件可以存在多個文件對象。一個文件對應的文件對象可能不是惟一的，但是其對應的索引節點和目錄項對象肯定是惟一的。

第二層： Ext2文件系統

VFS的下一層即是具體的文件系統，本節簡要介紹下Linux的Ext2文件系統。

一個文件系統一般使用塊設備上一個獨立的邏輯分區。對於Ext2文件系統來說，硬盤分區首先被劃分爲一個個的Block，一個Ext2文件系統上的每個Block都是一樣大小的。但是不同Ext2文件系統，Block大小可能不同，這是在創建Ext2系統決定的，一般爲1k或者4k。由於Block數量很多，爲了方便管理，Ext2將這些Block聚集在一起分爲幾個大的塊組（Block Group），每個塊組包含的等量的物理塊，在塊組的數據塊中存儲文件或目錄

Ext2中的Super Block和Inode Table分別對應VFS中的超級塊和索引結點，存放在磁盤。每個塊組都有一個塊組描述符GDT（Group Descriptor Table），存儲一個塊組的描述信息，例如在這個塊組中從哪裏開始是Inode表，從哪裏開始是數據塊等等。Block Bitmap和Inode Bitmap分別表示Block和Inode是否空閒可用。Data Block數據塊是用來真正存儲文件內容數據的地方，下面我們看一下具體的存儲規則。

在Ext2文件系統中所支持的Block大小有1K、2K、4K三種。在格式化時Block的大小就固定了，且每個Block都有編號，方便Inode的記錄。每個Block內最多隻能夠放置一個文件的數據，如果文件大於Block的大小，則一個文件會佔用多個Block；如果文件小於Block，則該Block的剩餘容量就不能夠再被使用了，即磁盤空間會浪費。下面看看Inode和Block的對應關係。

Inode要記錄的數據非常多，但大小僅爲固定的128字節，同時記錄一個Block號碼就需要4字節，假設一個文件有400MB且每個Block爲4K時，那麼至少也要十萬筆Block號碼的記錄。Inode不可能有這麼多的記錄信息，因此Ext2將Inode記錄Block號碼的區域定義爲12個直接、一個間接、一個雙間接與一個三間接記錄區。

最左邊爲Inode本身（128 bytes），裏面有12個直接指向Block號碼的對照，這12筆記錄能夠直接取得Block號碼。至於所謂的間接就是再拿一個Block來當作記錄Block號碼的記錄區，如果文件太大時，就會使用間接的Block來記錄編號。如上圖當中間接只是拿一個Block來記錄額外的號碼而已。 同理，如果文件持續長大，那麼就會利用所謂的雙間接，第一個Block僅再指出下一個記錄編號的Block在哪裏，實際記錄的在第二個Block當中。依此類推，三間接就是利用第三層Block來記錄編號。

第三層： Page Cache層

引入Cache層的目的是爲了提高Linux操作系統對磁盤訪問的性能。Cache層在內存中緩存了磁盤上的部分數據。當數據的請求到達時，如果在Cache中存在該數據且是最新的，則直接將數據傳遞給用戶程序，免除了對底層磁盤的操作，提高了性能。Cache層也正是磁盤IOPS爲什麼能突破200的主要原因之一。

在Linux的實現中，文件Cache分爲兩個層面，一是Page Cache，另一個Buffer Cache，每一個Page Cache包含若干Buffer Cache。Page Cache主要用來作爲文件系統上的文件數據的緩存來用，尤其是針對當進程對文件有read/write操作的時候。Buffer Cache則主要是設計用來在系統對塊設備進行讀寫的時候，對塊進行數據緩存的系統來使用。

磁盤Cache有兩大功能：預讀和回寫。預讀其實就是利用了局部性原理，具體過程是：對於每個文件的第一個讀請求，系統讀入所請求的頁面並讀入緊隨其後的少數幾個頁面（通常是三個頁面），這時的預讀稱爲同步預讀。對於第二次讀請求，如果所讀頁面不在Cache中，即不在前次預讀的頁中，則表明文件訪問不是順序訪問，系統繼續採用同步預讀；如果所讀頁面在Cache中，則表明前次預讀命中，操作系統把預讀頁的大小擴大一倍，此時預讀過程是異步的，應用程序可以不等預讀完成即可返回，只要後臺慢慢讀頁面即可，這時的預讀稱爲異步預讀。任何接下來的讀請求都會處於兩種情況之一：第一種情況是所請求的頁面處於預讀的頁面中，這時繼續進行異步預讀；第二種情況是所請求的頁面處於預讀頁面之外，這時系統就要進行同步預讀。

回寫是通過暫時將數據存在Cache裏，然後統一異步寫到磁盤中。通過這種異步的數據I/O模式解決了程序中的計算速度和數據存儲速度不匹配的鴻溝，減少了訪問底層存儲介質的次數，使存儲系統的性能大大提高。Linux 2.6.32內核之前，採用pdflush機制來將髒頁真正寫到磁盤中，什麼時候開始回寫呢？下面兩種情況下，髒頁會被寫回到磁盤：

1. 在空閒內存低於一個特定的閾值時，內核必須將髒頁寫回磁盤，以便釋放內存。
2. 當髒頁在內存中駐留超過一定的閾值時，內核必須將超時的髒頁寫會磁盤，以確保髒頁不會無限期地駐留在內存中。

回寫開始後，pdflush會持續寫數據，直到滿足以下兩個條件：

1. 已經有指定的最小數目的頁被寫回到磁盤。
2. 空閒內存頁已經回升，超過了閾值。

Linux 2.6.32內核之後，放棄了原有的pdflush機制，改成了bdi_writeback機制。bdi_writeback機制主要解決了原有fdflush機制存在的一個問題：在多磁盤的系統中，pdflush管理了所有磁盤的Cache，從而導致一定程度的I/O瓶頸。bdi_writeback機制爲每個磁盤都創建了一個線程，專門負責這個磁盤的Page Cache的刷新工作，從而實現了每個磁盤的數據刷新在線程級的分離，提高了I/O性能。

回寫機制存在的問題是回寫不及時引發數據丟失（可由sync|fsync解決），回寫期間讀I/O性能很差。

第四層： 通用塊層

通用塊層的主要工作是：接收上層發出的磁盤請求，並最終發出I/O請求。該層隱藏了底層硬件塊設備的特性，爲塊設備提供了一個通用的抽象視圖。

對於VFS和具體的文件系統來說，塊（Block）是基本的數據傳輸單元，當內核訪問文件的數據時，它首先從磁盤上讀取一個塊。但是對於磁盤來說，扇區是最小的可尋址單元，塊設備無法對比它還小的單元進行尋址和操作。由於扇區是磁盤的最小可尋址單元，所以塊不能比扇區還小，只能整數倍於扇區大小，即一個塊對應磁盤上的一個或多個扇區。一般來說，塊大小是2的整數倍，而且由於Page Cache層的最小單元是頁（Page），所以塊大小不能超過一頁的長度。

大多情況下，數據的傳輸通過DMA方式。舊的磁盤控制器，僅僅支持簡單的DMA操作：每次數據傳輸，只能傳輸磁盤上相鄰的扇區，即數據在內存中也是連續的。這是因爲如果傳輸非連續的扇區，會導致磁盤花費更多的時間在尋址操作上。而現在的磁盤控制器支持“分散/聚合”DMA操作，這種模式下，數據傳輸可以在多個非連續的內存區域中進行。爲了利用“分散/聚合”DMA操作，塊設備驅動必須能處理被稱爲段（segments）的數據單元。一個段就是一個內存頁面或一個頁面的部分，它包含磁盤上相鄰扇區的數據。

第五層： I/O調度層

I/O調度層的功能是管理塊設備的請求隊列。即接收通用塊層發出的I/O請求，緩存請求並試圖合併相鄰的請求。並根據設置好的調度算法，回調驅動層提供的請求處理函數，以處理具體的I/O請求。

如果簡單地以內核產生請求的次序直接將請求發給塊設備的話，那麼塊設備性能肯定讓人難以接受，因爲磁盤尋址是整個計算機中最慢的操作之一。爲了優化尋址操作，內核不會一旦接收到I/O請求後，就按照請求的次序發起塊I/O請求。爲此Linux實現了幾種I/O調度算法，算法基本思想就是通過合併和排序I/O請求隊列中的請求，以此大大降低所需的磁盤尋道時間，從而提高整體I/O性能。

常見的I/O調度算法包括Noop調度算法（No Operation）、CFQ（完全公正排隊I/O調度算法）、DeadLine（截止時間調度算法）、AS預測調度算法等。

• Noop算法：最簡單的I/O調度算法。該算法僅適當合併用戶請求，並不排序請求。新的請求通常被插在調度隊列的開頭或末尾，下一個要處理的請求總是隊列中的第一個請求。這種算法是爲不需要尋道的塊設備設計的，如SSD。因爲其他三個算法的優化是基於縮短尋道時間的，而SSD硬盤沒有所謂的尋道時間且I/O響應時間非常短。

• CFQ算法：算法的主要目標是在觸發I/O請求的所有進程中確保磁盤I/O帶寬的公平分配。算法使用許多個排序隊列，存放了不同進程發出的請求。通過散列將同一個進程發出的請求插入同一個隊列中。採用輪詢方式掃描隊列，從第一個非空隊列開始，依次調度不同隊列中特定個數（公平）的請求，然後將這些請求移動到調度隊列的末尾。

• Deadline算法：算法引入了兩個排隊隊列分別包含讀請求和寫請求，兩個最後期限隊列包含相同的讀和寫請求。本質就是一個超時定時器，當請求被傳給電梯算法時開始計時。一旦最後期限隊列中的超時時間已到，就想請求移至調度隊列末尾。Deadline算法避免了電梯調度策略（爲了減少尋道時間，會優先處理與上一個請求相近的請求）帶來的對某個請求忽略很長一段時間的可能。

• AS算法：AS算法本質上依據局部性原理，預測進程發出的讀請求與剛被調度的請求在磁盤上可能是“近鄰”。算法統計每個進程I/O操作信息，當剛剛調度了由某個進程的一個讀請求之後，算法馬上檢查排序隊列中的下一個請求是否來自同一個進程。如果是，立即調度下一個請求。否則，查看關於該進程的統計信息，如果確定進程p可能很快發出另一個讀請求，那麼就延遲一小段時間。

前文中計算出的IOPS是理論上的隨機讀寫的最大IOPS，在隨機讀寫中，每次I/O操作的尋址和旋轉延時都不能忽略不計，有了這兩個時間的存在也就限制了IOPS的大小。現在如果我們考慮在讀取一個很大的存儲連續分佈在磁盤的文件，因爲文件的存儲的分佈是連續的，磁頭在完成一個讀I/O操作之後，不需要重新尋址，也不需要旋轉延時，在這種情況下我們能到一個很大的IOPS值。這時由於不再考慮尋址和旋轉延時，則性能瓶頸僅是數據傳輸時延，假設數據傳輸時延爲0.4ms，那麼IOPS=1000 / 0.4 = 2500 IOPS。

在許多的開源框架如Kafka、HBase中，都通過追加寫的方式來儘可能的將隨機I/O轉換爲順序I/O，以此來降低尋址時間和旋轉延時，從而最大限度的提高IOPS。

第六層： 塊設備驅動層

驅動層中的驅動程序對應具體的物理塊設備。它從上層中取出I/O請求，並根據該I/O請求中指定的信息，通過向具體塊設備的設備控制器發送命令的方式，來操縱設備傳輸數據。這裏不再贅述。

4. 基於磁盤I/O特性設計的技巧

在上一節中我們瞭解了Linux系統中請求到達磁盤的一次完整過程，期間Linux通過Cache以及排序合併I/O請求來提高系統的性能。其本質就是由於磁盤隨機讀寫慢、順序讀寫快。本節針對常見開源系統闡述一些基於磁盤I/O特性的設計技巧。

採用追加寫

在進行系統設計時，良好的讀性能和寫性能往往不可兼得。在許多常見的開源系統中都是優先在保證寫性能的前提下來優化讀性能。那麼如何設計能讓一個系統擁有良好的寫性能呢？一個好的辦法就是採用追加寫，每次將數據添加到文件。由於完全是順序的，所以可以具有非常好的寫操作性能。但是這種方式也存在一些缺點：從文件中讀一些數據時將會需要更多的時間：需要倒序掃描，直到找到所需要的內容。當然在一些簡單的場景下也能夠保證讀操作的性能：

• 數據是被整體訪問，比如HDFS

  • HDFS建立在一次寫多次讀的模型之上。在HDFS中就是採用了追加寫並且設計爲高數據吞吐量；高吞吐量必然以高延遲爲代價，所以HDFS並不適用於對數據訪問要求低延遲的場景；由於採用是的追加寫，也並不適用於任意修改文件的場景。HDFS設計爲流式訪問大文件，使用大數據塊並且採用流式數據訪問來保證數據被整體訪問，同時最小化硬盤的尋址開銷，只需要一次尋址即可，這時尋址時間相比於傳輸時延可忽略，從而也擁有良好的讀性能。HDFS不適合存儲小文件，原因之一是由於NameNode內存不足問題，還有就是因爲訪問大量小文件需要執行大量的尋址操作，並且需要不斷的從一個datanode跳到另一個datanode，這樣會大大降低數據訪問性能。

• 知道文件明確的偏移量，比如Kafka

  • 在Kafka中，採用消息追加的方式來寫入每個消息，每個消息讀寫時都會利用Page Cache的預讀和後寫特性，同時partition中都使用順序讀寫，以此來提高I/O性能。雖然Kafka能夠根據偏移量查找到具體的某個消息，但是查找過程是順序查找，因此如果數據很大的話，查找效率就很低。所以Kafka中採用了分段和索引的方式來解決查找效率問題。Kafka把一個patition大文件又分成了多個小文件段，每個小文件段以偏移量命名，通過多個小文件段，不僅可以使用二分搜索法很快定位消息，同時也容易定期清除或刪除已經消費完的文件，減少磁盤佔用。爲了進一步提高查找效率，Kafka爲每個分段後的數據建立了索引文件，並通過索引文件稀疏存儲來降低元數據佔用大小。

在面對更復雜的讀場景（比如按key）時，如何來保證讀操作的性能呢？簡單的方式是像Kafka那樣，將文件數據有序保存，使用二分查找來優化效率；或者通過建索引的方式來進行優化；也可以採用hash的方式將數據分割爲不同的桶。以上的方法都能增加讀操作的性能，但是由於在數據上強加了數據結構，又會降低寫操作的性能。比如如果採用索引的方式來優化讀操作，那麼在更新索引時就需要更新B-tree中的特定部分，這時候的寫操作就是隨機寫。那麼有沒有一種辦法在保證寫性能不損失的同時也提供較好的讀性能呢？一個好的選擇就是使用LSM-tree。LSM-tree與B-tree相比，LSM-tree犧牲了部分讀操作，以此大幅提高寫性能。

• 日誌結構的合併樹LSM（The Log-Structured Merge-Tree）是HBase，LevelDB等NoSQL數據庫的存儲引擎。Log-Structured的思想是將整個磁盤看做一個日誌，在日誌中存放永久性數據及其索引，每次都添加到日誌的末尾。並且通過將很多小文件的存取轉換爲連續的大批量傳輸，使得對於文件系統的大多數存取都是順序的，從而提高磁盤I/O。LSM-tree就是這樣一種採用追加寫、數據有序以及將隨機I/O轉換爲順序I/O的延遲更新，批量寫入硬盤的數據結構。LSM-tree將數據的修改增量先保存在內存中，達到指定的大小限制後再將這些修改操作批量寫入磁盤。因此比較舊的文件不會被更新，重複的紀錄只會通過創建新的紀錄來覆蓋，這也就產生了一些冗餘的數據。所以系統會週期性的合併一些數據，移除重複的更新或者刪除紀錄，同時也會刪除上述的冗餘。在進行讀操作時，如果內存中沒有找到相應的key，那麼就是倒序從一個個磁盤文件中查找。如果文件越來越多那麼讀性能就會越來越低，目前的解決方案是採用頁緩存來減少查詢次數，週期合併文件也有助於提高讀性能。在文件越來越多時，可通過布隆過濾器來避免大量的讀文件操作。LSM-tree犧牲了部分讀性能，以此來換取寫入的最大化性能，特別適用於讀需求低，會產生大量插入操作的應用環境。

文件合併和元數據優化

目前的大多數文件系統，如XFS/Ext4、GFS、HDFS，在元數據管理、緩存管理等實現策略上都側重大文件。上述基於磁盤I/O特性設計的系統都有一個共性特點就是都運行在這些文件系統之上。這些文件系統在面臨海量時在性能和存儲效率方面都大幅降低，本節來探討下海量小文件下的系統設計。

常見文件系統在海量小文件應用下性能表現不佳的根本原因是磁盤最適合順序的大文件I/O讀寫模式，而非常不適合隨機的小文件I/O讀寫模式。主要原因體現在元數據管理低效和數據佈局低效：

• 元數據管理低效：由於小文件數據內容較少，因此元數據的訪問性能對小文件訪問性能影響巨大。Ext2文件系統中Inode和Data Block分別保存在不同的物理位置上，一次讀操作需要至少經過兩次的獨立訪問。在海量小文件應用下，Inode的頻繁訪問，使得原本的併發訪問轉變爲了海量的隨機訪問，大大降低了性能。另外，大量的小文件會快速耗盡Inode資源，導致磁盤儘管有大量Data Block剩餘也無法存儲文件，會浪費磁盤空間。

• 數據佈局低效：Ext2在Inode中使用多級指針來索引數據塊。對於大文件，數據塊的分配會盡量連續，這樣會具有比較好的空間局部性。但是對於小文件，數據塊可能零散分佈在磁盤上的不同位置，並且會造成大量的磁盤碎片，不僅造成訪問性能下降，還大量浪費了磁盤空間。數據塊一般爲1KB、2KB或4KB，對於小於4KB的小文件，Inode與數據的分開存儲破壞了空間局部性，同時也造成了大量的隨機I/O。

對於海量小文件應用，常見的I/O流程複雜也是造成磁盤性能不佳的原因。對於小文件，磁盤的讀寫所佔用的時間較少，而用於文件的open()操作佔用了絕大部分系統時間，導致磁盤有效服務時間非常低，磁盤性能低下。針對於問題的根源，優化的思路大體上分爲：

• 針對數據佈局低效，採用小文件合併策略，將小文件合併爲大文件。
• 針對元數據管理低效，優化元數據的存儲和管理。針對這兩種優化方式，業內也出現了許多優秀的開源軟件。

小文件合併 小文件合併爲大文件後，首先減少了大量元數據，提高了元數據的檢索和查詢效率，降低了文件讀寫的I/O操作延時。其次將可能連續訪問的小文件一同合併存儲，增加了文件之間的局部性，將原本小文件間的隨機訪問變爲了順序訪問，大大提高了性能。同時，合併存儲能夠有效的減少小文件存儲時所產生的磁盤碎片問題，提高了磁盤的利用率。最後，合併之後小文件的訪問流程也有了很大的變化，由原來許多的open操作轉變爲了seek操作，定位到大文件具體的位置即可。如何尋址這個大文件中的小文件呢？其實就是利用一個旁路數據庫來記錄每個小文件在這個大文件中的偏移量和長度等信息。其實小文件合併的策略本質上就是通過分層的思想來存儲元數據。中控節點存儲一級元數據，也就是大文件與底層塊的對應關係；數據節點存放二級元數據，也就是最終的用戶文件在這些一級大塊中的存儲位置對應關係，經過兩級尋址來讀寫數據。

• 淘寶的TFS就採用了小文件合併存儲的策略。TFS中默認Block大小爲64M，每個塊中會存儲許多不同的小文件，但是這個塊只佔用一個Inode。假設一個Block爲64M，數量級爲1PB。那麼NameServer上會有 1 * 1024 * 1024 * 1024 / 64 = 16.7M個Block。假設每個Block的元數據大小爲0.1K，則佔用內存不到2G。在TFS中，文件名中包含了Block ID和File ID，通過Block ID定位到具體的DataServer上，然後DataServer會根據本地記錄的信息來得到File ID所在Block的偏移量，從而讀取到正確的文件內容。

元數據管理優化 一般來說元數據信息包括名稱、文件大小、設備標識符、用戶標識符、用戶組標識符等等，在小文件系統中可以對元數據信息進行精簡，僅保存足夠的信息即可。元數據精簡可以減少元數據通信延時，同時相同容量的Cache能存儲更多的元數據，從而提高元數據使用效率。另外可以在文件名中就包含元數據信息，從而減少一個元數據的查詢操作。最後針對特別小的一些文件，可以採取元數據和數據並存的策略，將數據直接存儲在元數據之中，通過減少一次尋址操作從而大大提高性能。

• TFS中文件命名就隱含了位置信息等部分元數據，從而減少了一個元數據的查詢操作。在Rerserfs中，對於小於1KB的小文件，Rerserfs可以將數據直接存儲在Inode中。

本文從磁盤性能指標出發，探究了操作系統與磁盤的交互以及對磁盤讀寫的優化，最後列舉了一些常用開源系統中基於磁盤I/O特性的設計特點。期望通過展現磁盤I/O的特性，爲存儲系統設計和解決一些系統性能問題提供一種新思路。

原文：https://tech.meituan.com/2017/05/19/about-desk-io.html