歡迎光臨
每天分享高質量文章

塊層介紹 第一篇: bio層

原文鏈接:https://lwn.net/Articles/736534/

摘要: 本文翻譯自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 層”,這將是我們在下一篇討論的話題。

赞(0)

分享創造快樂