原文鏈接：https://lwn.net/Articles/736534/，本翻譯稿最先發表在陳莉君老師的Linux內核之旅公衆號
本博文二次轉載自 Linux閱馬場 發佈的轉載文
摘要
本文翻譯自 Neil Brown 發表在 LWN 上的兩篇介紹塊層的文章。Neil是前 MD RAID 的 maintainer，他通過這兩篇文章，提綱契領地描繪了塊層的主脈絡。
概述
操作系統比如Linux關鍵的價值之一，就是爲具體的設備提供了抽象接口。雖然後來出現了各種其它抽象模型比如“網絡設備”和“位圖顯示（bitmap display）”，但是最初的“字符設備”和“塊設備”兩種類型的設備抽象依然地位顯赫。近幾年持久化內存(persistent memory)炙手可熱，[與非易失性存儲NVRAM概念不同, persistent memory強調以內存訪問方式讀寫持久存儲，完全不同與塊設備層], 但在將來很長一段時間內，塊設備接口仍然是持久存儲(persistent storage)的主角。這兩篇文章的目的就是去揭開這位主角的面紗。
術語塊層常指Linux內核中非常重要的一部分 - 這部分實現了應用程序和文件系統訪問存儲設備的接口。 塊層是由哪些代碼組成的呢？ 這個問題沒有準確的答案。一個最簡單的答案是在 block子目錄 下的所有源碼。這些代碼又可被看作兩層，這兩層之間緊密聯繫但有明顯的區別。我知道這兩個子層次還沒有公認的命名，因此這裏就稱作 bio層 和 request 層 吧。本文將帶我們先了解 bio層 ，而在下一篇文章中討論 request層。
塊層之上
在深挖bio層之前，很有必要先了解點背景知識，看看塊層之上的天地。這裏“之上”意思是靠近用戶空間（the top），遠離硬件(the bottom)，包括所有使用塊層服務的代碼。
通常，我們可以通過 /dev 目錄下的塊設備文件來訪問塊設備，在內核中塊設備文件會映射到一個有S_IFBLK標記的 inode。這些 inode 有點像符號鏈接，本身不代表一個塊設備，而是一個指向塊設備的指針。更細地說，inode結構體的i_bdev域會指向一個代表目標設備的struct block_device對象。 struct block_device包含一個指向第二個inode的域：block_device->bd_inode， 這個 inode 會在塊設備IO中起作用，而 /dev 目錄下的 inode 只是一個指針而已。
第二個 inode 所起的主要作用（實現代碼主要在fs/block_dev.c, fs/buffer.c，等）就是提供 page cache。如果設備文件打開時沒有加O_DIRECT標誌，與 inode 關聯的 page cache 用來緩存預讀數據，或緩存寫數據直到回寫(writeback)過程將髒頁刷到塊設備上。如果用了O_DIRECT，讀和寫繞過 page cache 直接向塊設備發請求。相似地，當一個塊設備格式化並掛載成文件系統時，讀和寫操作通常會直接作用在塊設備上 [作者寫錯了？]，儘管一些文件系統（尤其是ext*家族）能夠訪問相同的 page cache （過去稱爲buffer cache）來管理一些文件系統數據。
open()另一個與塊設備相關的標誌是O_EXCL。塊設備有個簡單的勸告鎖(advisory-locking)模型，每個塊設備最多隻能有個“持有者”(holder)。在激活一個塊設備時，[激活泛指驅動一個塊設備的過程，包括向內核添加代表塊設備的對象，註冊請求隊列等]，可用blkdev_get()函數爲塊設備指定一個"持有者"。[ blkdev_get()的原型： int blkdev_get(struct block_device *bdev, fmode_t mode, void *holder)， holder可以是一個文件系統的超級塊, 也可以是一個掛載點等]。一旦塊設備有了“持有者”，隨後再試圖激活該設備就會失敗。通常在掛載時，文件系統會爲塊設備指定一個“持有者”，來保證互斥使用塊設備。當一個應用程序試圖以O_EXCL方式打開塊設備時，內核會新建一個struct file對象並把它作爲塊設備的“持有者”，假如這個塊設備作爲文件系統已經被掛載，打開操作就會失敗。如果open()操作成功並且還沒有關上，嘗試掛載操作就會阻塞。但是，如果塊設備不是以O_EXCL打開的，那麼O_EXCL就不能阻止塊設備被同時打開，O_EXCL只是便於應用程序測試塊設備是否正在使用中。
無論以什麼方式訪問塊設備，主要接口都是發送讀寫請求，或其它特殊請求比如 discard 操作， 最終接收處理結果。bio層就是要提供這樣的服務。
bio層
Linux中塊設備用struct gendisk表示，即 一個通用磁盤 (generic disk)。這個結構體也沒包含太多信息，主要起承上啓下的作用，上承文件系統，下啓塊層。往上層走，一個gendisk對象會關聯到block_device 對象，如我們上文所述， block_device 對象被鏈接到 /dev 目錄下的 inode 中。如果一個物理塊設備包含多個分區，也就說有個分區表，那麼這個 gendisk對象 就對應多個 block_device 對象。其中，有一個 block_device 對象代表着整個物理磁盤gendisk，而其它block_device各代表gendisk中的一個分區。
struct bio是 bio 層一個重要的數據結構，用來表示來自 block_device對象 的讀寫請求，以及各種其它的控制類請求，然後把這些請求傳達到驅動層。一個 bio對象 包括的信息有目標設備，設備地址空間上的偏移量，請求類型（通常是讀或寫），讀寫大小，和用來存放數據的內存區域。在Linux 4.14之前，bio對象 是用 block_device 來表示目標設備的。而現在bio對象包含一個指向 gendisk 結構體的指針和分區號，這些可通過bio_set_dev()函數設置。這樣做突出了 gendisk結構體 的核心地位，更自然一些。
一個 bio 一旦構造好，上層代碼就可以調用generic_make_request()或submit_bio()提交給bio層處理。[submit_bio()只是generic_make_request()的一個簡單封裝]。 通常，上層代碼不會等待請求處理完成，而是把請求放到塊設備隊列上就返回了。generic_make_request()有時可能阻塞一小會，比如在等待內存分配的時候，這樣想可能更容易理解，它也許要等待一些已經在隊列上的請求處理完成，然後騰出空間。如果 bi_opf域 上設置了REQ_NOWAIT標誌，generic_make_request()在任何情況下都不應該阻塞，而應該把這個bio的返回狀態設置成BLK_STS_AGAIN或BLK_STS_NOTSUPP,然後立即返回。截至寫作時，這個功能還沒有完全實現。
bio層和request層間的接口需要設備驅動調用blk_queue_make_request()來註冊一個make_request_fn()函數，這樣generic_make_request()就可以通過回調這個函數來處理提交個這個塊設備的 bio請求 了。make_request_fn()函數負責如何處理bio請求，當IO請求完成時，調用bio_endio()設置 bi_status域 的狀態來表示請求是否處理成功，並回調保存在bio結構體裏的bi_end_io函數。
除了上述對bio請求的簡單處理，bio層最有意思的兩個功能就是：避免遞歸調用(recursion avoidance)和隊列激活（queue plugging）。
避免遞歸(recursion avoidance)
在存儲方案裏，經常用到"md" [mutiple device] (軟RAID就是md的一個實例)和"dm" [device mapper] (用於multipath和LVM2）這兩種虛擬設備，也常叫做棧式設備，由多個塊設備按樹的形式組織起來，它們會沿着設備樹往下一層一層對bio請求作修改和傳遞。如果採用遞歸的簡單的實現，在設備樹很深的情況下，會佔用大量的內核棧空間。很久以前 (Linux 2.6.22)，這個問題時不時會發生，在使用一些本身就因遞歸調用佔用大量內核棧空間的文件系統時，情況更加糟糕。
爲了避免遞歸，generic_make_request()會進行檢測，如果發現遞歸，就不會把bio請求發送到下一層設備上。這種情況下，generic_make_request()會把bio請求放到進程內部的一個隊列上(currect->bio_list， struct task_struct的一個域)， 等到上一次的 bio請求 處理完以後，然後再提交這一層的請求。由於generic_make_request()不會阻塞以等待bio處理完成，即使延遲一會再處理請求都是沒問題的。
通常，這個避免遞歸的方法都工作得很完美，但有時候可能發生死鎖。理解死鎖如何發生的關鍵就是上文我們對bio提交方式的觀察: 當遞歸發生時，bio要排隊等待之前已經提交的bio處理完成。如果要等的bio一直在current->bio_list隊列上而得不到處理，它就會一直等下去。
引起bio互相等待而產生死鎖的原因，不太容易發現，通常都是在測試中發現的，而不是分析代碼發現的。以bio拆分 (bio split)爲例，當一個bio的目標設備在大小或對齊上有限制時，make_request_fn()可能會把bio拆成兩部分，然後再分別處理。bio層提供了兩個函數（bio_split()和bio_chain()），使得bio拆分很容易，但是bio拆分需要給第二個bio結構體分配空間。在塊層代碼裏分配內存要特別小心，尤其當內存緊張時，Linux在回收內存時，需要把髒頁通過塊層寫出去。如果在內存寫出的時候，又需要分配內存，那就麻煩了。一個標準的機制就是使用mempool，爲一個某種關鍵目的預留一些內存。從mempool分配內存需要等待其它mempool的使用者歸還一些內存，而不用等待整個內存回收算法完成。當使用mempool分配bio內存時，這種等待可能會導致generic_make_request()死鎖。
社區已經有多次嘗試提供一個簡單的方式來避免死鎖。一個是引入了bioset 進程，你可以用ps命令在電腦上查看。這個機制主要關注的就是解決上面描述的死鎖問題，爲每一個分配bio的"mempool"分配一個"rescuer"線程。如果發現bio分配不出來，所有在currect->bio_list的bio就會被取下來，交個相應的bioset線程來處理。這個方法相當複雜，導致創建了很多bioset線程，但是大多時候派不上用場，只是爲了解決一個特殊的死鎖情況，代價太高了。通常，死鎖跟bio拆分有關係，但是它們不總是要等待mempool分配。[最後這句話，有些突兀]
最新的內核通常不會創建bioset線程了，而只是在幾種個別情況下才會創建。Linux 4.11內核，引入了另一個解決方案，對generic_make_request()做了改動，好處是更通用，代價小，但是卻對驅動程序提出了一點要求。主要的要求是在發生bio拆分時，其中一個bio要直接提交給generic_make_request()來安排最合適的時間處理，另一個bio可以用任何合適的方式處理，這樣generic_make_request()就有了更強的控制力。 根據bio在提交時在設備棧中的深度，對bio進行排序後，總是先處理更低層設備的bio, 再處理較高層設備的bio。這個簡單的策略避免了所有惱人的死鎖問題。
塊隊列激活（queue plugging）
存儲設備處理單個IO請求的代價通常挺高的，因此提高處理效率的一個辦法就是把多個請求聚集起來，然後做一次批量提交。對於慢速設備來說，隊列上積攢的請求通常會多一些，那麼做批處理的機會就多。但是，對於快速設備，或經常處於空閒狀態的慢速設備來說，做批處理的機會就顯然少了很多。爲了解決這個問題，Linux塊層提出了一個機制叫"plugging"。[plugging, 即堵上塞子，隊列就像水池，請求就像水，堵上塞子就可以蓄水了]
原來，plugging僅僅在隊列爲空的時候才使用。在向一個空隊列提交請求前，這個隊列就會被“堵塞”上一會時間，好讓請求積蓄起來，暫時不往底層設備提交。文件系統提交的bio就會排起隊來，以便做批處理。文件系統可以主動請求，或着定時器週期性超時，來拔開塞子。我們預期的是在一定時間內聚集一批請求，然後在一點延遲後就開始真正處理IO，而不是一直聚積特別多的請求。從Linux 2.6.30開始，有了一個新的plugging機制，把積蓄請求的對象，從面向每個設備，改成了面向每個進程。這個改進在多處理器上擴張性很好。
當文件系統，或其它塊設備的使用者在提交請求時，通常會在調用generic_make_request()前後加上blk_start_plug()和blk_finish_plug()。 blk_start_plug()會初始化一個struct blk_plug結構體，讓 current->plug 指向它，這個結構體裏面包含一個請求列表(我們會在下一篇文章細說這個)。因爲這個請求列表是每個進程就有一個，所以在往列表裏添加請求時不用上鎖。如果可以更高效率的處理請求，make_request_fn()就會把bio添加到這個列表上。
當blk_finish_plug()被調用時，或調用schedule()進行進程切換時(比如，等待mutex鎖，等待內存分配等)，保存在current->plug列表上的所有請求就要往底層設備提交，就是說進程不能身負IO請求去睡覺。
調用schedule()進行進程切換時，積蓄的bio會被全部處理，這個事實意爲着bio處理的延遲只會發生在新的bio請求不斷產生期間。假如進程因等待要進入睡眠，那麼積蓄起來的bio就會被立即處理。這樣可以避免出現循環等待的問題，試想一個進程在等待一個bio請求處理完成而進入睡眠，但是這個bio請求還在plug列表上並沒有下發給底層設備。
像這樣進程級別的plugging機制，主要的好處一是相關性最強的bio會更容易聚集起來，以便批量處理，二是這樣很大程度上減少了隊列鎖的競爭。如果沒有進程級別的plugging處理，那麼每一個bio請求到來時，都要進行一次spinlock或原子操作。有了這樣的機制，每一個進程就有一個bio列表，把進程bio列表往設備隊列裏合併時，只需要上一次鎖就夠了。
bio層及以下(bio layer and below)
總之，bio層不是很複雜，它將IO請求以bio結構體的方式直接傳遞給相應的make_request_fn() [具體的實現有通用塊層的blk_queue_bio(), DM設備的dm_make_request(), MD設備的md_make_request()]。bio層實現了各種通用的函數，來幫助設備驅動層處理bio拆分，scheduling the sub-bios [不會翻譯這個，意思應該是安排拆分後的bio如何處理], "plugging"請求等。 bio層也會做一些簡單操作，比如更新/proc/vmstat中的pgpgin和pgpgout的計數，然後把IO請求的大部分操作交給下一層處理 [request層]。
有時候，bio層的下一層就是最終的驅動，比如說DRBD（The Distributed Replicated Block Device）或 BRD (a RAM based block device). 更常見的下一層有MD和DM提供這種虛擬設備的中間層。不可或缺的一層，就是除bio層之外剩下的部分了，我稱之爲"request 層"，這將是我們在下一篇討論的話題。