操作系統(tǒng)比如Linux關(guān)鍵的價值之一，就是為具體的設(shè)備提供了抽象接口。雖然后來出現(xiàn)了各種其它抽象模型比如“網(wǎng)絡(luò)設(shè)備”和“位圖顯示（bitmap display）”，但是最初的“字符設(shè)備”和“塊設(shè)備”兩種類型的設(shè)備抽象依然地位顯赫。近幾年持久化內(nèi)存(persistent memory)炙手可熱，[與非易失性存儲NVRAM概念不同, persistent memory強調(diào)以內(nèi)存訪問方式讀寫持久存儲，完全不同與塊設(shè)備層], 但在將來很長一段時間內(nèi)，塊設(shè)備接口仍然是持久存儲(persistent storage)的主角。這兩篇文章的目的就是去揭開這位主角的面紗。

術(shù)語“塊層”常指Linux內(nèi)核中非常重要的一部分 - 這部分實現(xiàn)了應(yīng)用程序和文件系統(tǒng)訪問存儲設(shè)備的接口。 塊層是由哪些代碼組成的呢？ 這個問題沒有準確的答案。一個最簡單的答案是在"block"子目錄下的所有源碼。這些代碼又可被看作兩層，這兩層之間緊密聯(lián)系但有明顯的區(qū)別。我知道這兩個子層次還沒有公認的命名，因此這里就稱作“bio層”和“request 層”吧。本文將帶我們先了解"bio層"，而在下一篇文章中討論“request層”。

塊層之上

在深挖bio層之前，很有必要先了解點背景知識，看看塊層之上的天地。這里“之上”意思是靠近用戶空間（the top），遠離硬件(the bottom)，包括所有使用塊層服務(wù)的代碼。

通常，我們可以通過/dev目錄下的塊設(shè)備文件來訪問塊設(shè)備，在內(nèi)核中塊設(shè)備文件會映射到一個有S_IFBLK標記的inode。這些inode有點像符號鏈接，本身不代表一個塊設(shè)備，而是一個指向塊設(shè)備的指針。更細地說，inode結(jié)構(gòu)體的i_bdev域會指向一個代表目標設(shè)備的struct block_device對象。 struct block_device包含一個指向第二個inode的域：block_device->bd_inode， 這個inode會在塊設(shè)備IO中起作用，而/dev目錄下的inode只是一個指針而已。

第二個inode所起的主要作用（實現(xiàn)代碼主要在fs/block_dev.c, fs/buffer.c，等）就是提供page cache。如果設(shè)備文件打開時沒有加O_DIRECT標志，與inode關(guān)聯(lián)的page cache用來緩存預(yù)讀數(shù)據(jù)，或緩存寫數(shù)據(jù)直到回寫(writeback)過程將臟頁刷到塊設(shè)備上。如果用了O_DIRECT，讀和寫繞過page cache直接向塊設(shè)備發(fā)請求。相似地，當一個塊設(shè)備格式化并掛載成文件系統(tǒng)時，讀和寫操作通常會直接作用在塊設(shè)備上 [作者寫錯了？]，盡管一些文件系統(tǒng)（尤其是ext*家族）能夠訪問相同的page cache（過去稱為buffer cache）來管理一些文件系統(tǒng)數(shù)據(jù)。

open()另一個與塊設(shè)備相關(guān)的標志是O_EXCL。塊設(shè)備有個簡單的勸告鎖(advisory-locking)模型，每個塊設(shè)備最多只能有個“持有者”(holder)。在激活一個塊設(shè)備時，[激活泛指驅(qū)動一個塊設(shè)備的過程，包括向內(nèi)核添加代表塊設(shè)備的對象，注冊請求隊列等]，可用blkdev_get()函數(shù)為塊設(shè)備指定一個"持有者"。[ blkdev_get()的原型： int blkdev_get(struct block_device *bdev, fmode_t mode, void *holder)， holder可以是一個文件系統(tǒng)的超級塊, 也可以是一個掛載點等]。一旦塊設(shè)備有了“持有者”，隨后再試圖激活該設(shè)備就會失敗。通常在掛載時，文件系統(tǒng)會為塊設(shè)備指定一個“持有者”，來保證互斥使用塊設(shè)備。當一個應(yīng)用程序試圖以O(shè)_EXCL方式打開塊設(shè)備時，內(nèi)核會新建一個struct file對象并把它作為塊設(shè)備的“持有者”，假如這個塊設(shè)備作為文件系統(tǒng)已經(jīng)被掛載，打開操作就會失敗。如果open()操作成功并且還沒有關(guān)上，嘗試掛載操作就會阻塞。但是，如果塊設(shè)備不是以O(shè)_EXCL打開的，那么O_EXCL就不能阻止塊設(shè)備被同時打開，O_EXCL只是便于應(yīng)用程序測試塊設(shè)備是否正在使用中。

無論以什么方式訪問塊設(shè)備，主要接口都是發(fā)送讀寫請求，或其它特殊請求比如discard操作， 最終接收處理結(jié)果。bio層就是要提供這樣的服務(wù)。

bio層

Linux中塊設(shè)備用struct gendisk表示，即 一個通用磁盤 (generic disk)。這個結(jié)構(gòu)體也沒包含太多信息，主要起承上啟下的作用，上承文件系統(tǒng)，下啟塊層。往上層走，一個gendisk對象會關(guān)聯(lián)到block_device對象，如我們上文所述，block_device對象被鏈接到/dev目錄下的inode中。如果一個物理塊設(shè)備包含多個分區(qū)，也就說有個分區(qū)表，那么這個gendisk對象就對應(yīng)多個block_device對象。其中，有一個block_device對象代表著整個物理磁盤gendisk，而其它block_device各代表gendisk中的一個分區(qū)。

struct bio是bio層一個重要的數(shù)據(jù)結(jié)構(gòu)，用來表示來自block_device對象的讀寫請求，以及各種其它的控制類請求，然后把這些請求傳達到驅(qū)動層。一個bio對象包括的信息有目標設(shè)備，設(shè)備地址空間上的偏移量，請求類型（通常是讀或?qū)懀x寫大小，和用來存放數(shù)據(jù)的內(nèi)存區(qū)域。在Linux 4.14之前，bio對象是用block_device來表示目標設(shè)備的。而現(xiàn)在bio對象包含一個指向gendisk結(jié)構(gòu)體的指針和分區(qū)號，這些可通過bio_set_dev()函數(shù)設(shè)置。這樣做突出了gendisk結(jié)構(gòu)體的核心地位，更自然一些。

一個bio一旦構(gòu)造好，上層代碼就可以調(diào)用generic_make_request()或submit_bio()提交給bio層處理。[submit_bio()只是generic_make_request()的一個簡單封裝]。 通常，上層代碼不會等待請求處理完成，而是把請求放到塊設(shè)備隊列上就返回了。generic_make_request()有時可能阻塞一小會，比如在等待內(nèi)存分配的時候，這樣想可能更容易理解，它也許要等待一些已經(jīng)在隊列上的請求處理完成，然后騰出空間。如果bi_opf域上設(shè)置了REQ_NOWAIT標志，generic_make_request()在任何情況下都不應(yīng)該阻塞，而應(yīng)該把這個bio的返回狀態(tài)設(shè)置成BLK_STS_AGAIN或BLK_STS_NOTSUPP,然后立即返回。截至寫作時，這個功能還沒有完全實現(xiàn)。

bio層和request層間的接口需要設(shè)備驅(qū)動調(diào)用blk_queue_make_request()來注冊一個make_request_fn()函數(shù)，這樣generic_make_request()就可以通過回調(diào)這個函數(shù)來處理提交個這個塊設(shè)備的bio請求了。make_request_fn()函數(shù)負責(zé)如何處理bio請求，當IO請求完成時，調(diào)用bio_endio()設(shè)置bi_status域的狀態(tài)來表示請求是否處理成功，并回調(diào)保存在bio結(jié)構(gòu)體里的bi_end_io函數(shù)。

除了上述對bio請求的簡單處理，bio層最有意思的兩個功能就是：避免遞歸調(diào)用(recursion avoidance)和隊列激活（queue plugging）。

避免遞歸(recursion avoidance)

在存儲方案里，經(jīng)常用到"md" [mutiple device] (軟RAID就是md的一個實例)和"dm" [device mapper] (用于multipath和LVM2）這兩種虛擬設(shè)備，也常叫做棧式設(shè)備，由多個塊設(shè)備按樹的形式組織起來，它們會沿著設(shè)備樹往下一層一層對bio請求作修改和傳遞。如果采用遞歸的簡單的實現(xiàn)，在設(shè)備樹很深的情況下，會占用大量的內(nèi)核?？臻g。很久以前 (Linux 2.6.22)，這個問題時不時會發(fā)生，在使用一些本身就因遞歸調(diào)用占用大量內(nèi)核?？臻g的文件系統(tǒng)時，情況更加糟糕。

為了避免遞歸，generic_make_request()會進行檢測，如果發(fā)現(xiàn)遞歸，就不會把bio請求發(fā)送到下一層設(shè)備上。這種情況下，generic_make_request()會把bio請求放到進程內(nèi)部的一個隊列上(currect->bio_list， struct task_struct的一個域)， 等到上一次的bio請求處理完以后，然后再提交這一層的請求。由于generic_make_request()不會阻塞以等待bio處理完成，即使延遲一會再處理請求都是沒問題的。

通常，這個避免遞歸的方法都工作得很完美，但有時候可能發(fā)生死鎖。理解死鎖如何發(fā)生的關(guān)鍵就是上文我們對bio提交方式的觀察: 當遞歸發(fā)生時，bio要排隊等待之前已經(jīng)提交的bio處理完成。如果要等的bio一直在current->bio_list隊列上而得不到處理，它就會一直等下去。

引起bio互相等待而產(chǎn)生死鎖的原因，不太容易發(fā)現(xiàn)，通常都是在測試中發(fā)現(xiàn)的，而不是分析代碼發(fā)現(xiàn)的。以bio拆分 (bio split)為例，當一個bio的目標設(shè)備在大小或?qū)R上有限制時，make_request_fn()可能會把bio拆成兩部分，然后再分別處理。bio層提供了兩個函數(shù)（bio_split()和bio_chain()），使得bio拆分很容易，但是bio拆分需要給第二個bio結(jié)構(gòu)體分配空間。在塊層代碼里分配內(nèi)存要特別小心，尤其當內(nèi)存緊張時，Linux在回收內(nèi)存時，需要把臟頁通過塊層寫出去。如果在內(nèi)存寫出的時候，又需要分配內(nèi)存，那就麻煩了。一個標準的機制就是使用mempool，為一個某種關(guān)鍵目的預(yù)留一些內(nèi)存。從mempool分配內(nèi)存需要等待其它mempool的使用者歸還一些內(nèi)存，而不用等待整個內(nèi)存回收算法完成。當使用mempool分配bio內(nèi)存時，這種等待可能會導(dǎo)致generic_make_request()死鎖。

社區(qū)已經(jīng)有多次嘗試提供一個簡單的方式來避免死鎖。一個是引入了"bioset" 進程，你可以用ps命令在電腦上查看。這個機制主要關(guān)注的就是解決上面描述的死鎖問題，為每一個分配bio的"mempool"分配一個"rescuer"線程。如果發(fā)現(xiàn)bio分配不出來，所有在currect->bio_list的bio就會被取下來，交個相應(yīng)的bioset線程來處理。這個方法相當復(fù)雜，導(dǎo)致創(chuàng)建了很多bioset線程，但是大多時候派不上用場，只是為了解決一個特殊的死鎖情況，代價太高了。通常，死鎖跟bio拆分有關(guān)系，但是它們不總是要等待mempool分配。[最后這句話，有些突兀]

最新的內(nèi)核通常不會創(chuàng)建bioset線程了，而只是在幾種個別情況下才會創(chuàng)建。Linux 4.11內(nèi)核，引入了另一個解決方案，對generic_make_request()做了改動，好處是更通用，代價小，但是卻對驅(qū)動程序提出了一點要求。主要的要求是在發(fā)生bio拆分時，其中一個bio要直接提交給generic_make_request()來安排最合適的時間處理，另一個bio可以用任何合適的方式處理，這樣generic_make_request()就有了更強的控制力。 根據(jù)bio在提交時在設(shè)備棧中的深度，對bio進行排序后，總是先處理更低層設(shè)備的bio, 再處理較高層設(shè)備的bio。這個簡單的策略避免了所有惱人的死鎖問題。

塊隊列激活（queue plugging）

存儲設(shè)備處理單個IO請求的代價通常挺高的，因此提高處理效率的一個辦法就是把多個請求聚集起來，然后做一次批量提交。對于慢速設(shè)備來說，隊列上積攢的請求通常會多一些，那么做批處理的機會就多。但是，對于快速設(shè)備，或經(jīng)常處于空閑狀態(tài)的慢速設(shè)備來說，做批處理的機會就顯然少了很多。為了解決這個問題，Linux塊層提出了一個機制叫"plugging"。[plugging, 即堵上塞子，隊列就像水池，請求就像水，堵上塞子就可以蓄水了]

原來，plugging僅僅在隊列為空的時候才使用。在向一個空隊列提交請求前，這個隊列就會被“堵塞”上一會時間，好讓請求積蓄起來，暫時不往底層設(shè)備提交。文件系統(tǒng)提交的bio就會排起隊來，以便做批處理。文件系統(tǒng)可以主動請求，或著定時器周期性超時，來拔開塞子。我們預(yù)期的是在一定時間內(nèi)聚集一批請求，然后在一點延遲后就開始真正處理IO，而不是一直聚積特別多的請求。從Linux 2.6.30開始，有了一個新的plugging機制，把積蓄請求的對象，從面向每個設(shè)備，改成了面向每個進程。這個改進在多處理器上擴張性很好。

當文件系統(tǒng)，或其它塊設(shè)備的使用者在提交請求時，通常會在調(diào)用generic_make_request()前后加上blk_start_plug()和blk_finish_plug()。 blk_start_plug()會初始化一個struct blk_plug結(jié)構(gòu)體，讓current->plug指向它，這個結(jié)構(gòu)體里面包含一個請求列表(我們會在下一篇文章細說這個)。因為這個請求列表是每個進程就有一個，所以在往列表里添加請求時不用上鎖。如果可以更高效率的處理請求，make_request_fn()就會把bio添加到這個列表上。

當blk_finish_plug()被調(diào)用時，或調(diào)用schedule()進行進程切換時(比如，等待mutex鎖，等待內(nèi)存分配等)，保存在current->plug列表上的所有請求就要往底層設(shè)備提交，就是說進程不能身負IO請求去睡覺。

調(diào)用schedule()進行進程切換時，積蓄的bio會被全部處理，這個事實意為著bio處理的延遲只會發(fā)生在新的bio請求不斷產(chǎn)生期間。假如進程因等待要進入睡眠，那么積蓄起來的bio就會被立即處理。這樣可以避免出現(xiàn)循環(huán)等待的問題，試想一個進程在等待一個bio請求處理完成而進入睡眠，但是這個bio請求還在plug列表上并沒有下發(fā)給底層設(shè)備。

像這樣進程級別的plugging機制，主要的好處一是相關(guān)性最強的bio會更容易聚集起來，以便批量處理，二是這樣很大程度上減少了隊列鎖的競爭。如果沒有進程級別的plugging處理，那么每一個bio請求到來時，都要進行一次spinlock或原子操作。有了這樣的機制，每一個進程就有一個bio列表，把進程bio列表往設(shè)備隊列里合并時，只需要上一次鎖就夠了。

bio層及以下(bio layer and below)

總之，bio層不是很復(fù)雜，它將IO請求以bio結(jié)構(gòu)體的方式直接傳遞給相應(yīng)的make_request_fn() [具體的實現(xiàn)有通用塊層的blk_queue_bio(), DM設(shè)備的dm_make_request(), MD設(shè)備的md_make_request()]。bio層實現(xiàn)了各種通用的函數(shù)，來幫助設(shè)備驅(qū)動層處理bio拆分，scheduling the sub-bios [不會翻譯這個，意思應(yīng)該是安排拆分后的bio如何處理], "plugging"請求等。 bio層也會做一些簡單操作，比如更新/proc/vmstat中的pgpgin和pgpgout的計數(shù)，然后把IO請求的大部分操作交給下一層處理 [request層]。

有時候，bio層的下一層就是最終的驅(qū)動，比如說DRBD（The Distributed Replicated Block Device）或 BRD (a RAM based block device). 更常見的下一層有MD和DM提供這種虛擬設(shè)備的中間層。不可或缺的一層，就是除bio層之外剩下的部分了，我稱之為"request 層"，這將是我們在下一篇討論的話題。