前言

Block Layer層在整個(gè)I/O中負(fù)責(zé)承上啟下，上接文件系統(tǒng)，下接塊驅(qū)動(dòng)。
我不想直接討論代碼，希望從一個(gè)架構(gòu)的演變來初探一下Block Layer層。

一、1.0版本

首先我們來了解幾個(gè)重要的數(shù)據(jù)結(jié)構(gòu)

1.1 bio

bio代表了一次I/0請求，代表一個(gè)塊設(shè)備的一個(gè)扇區(qū)或者多個(gè)連續(xù)扇區(qū)的數(shù)據(jù)請求，扇區(qū)是塊設(shè)備的最小訪問單元，bio是文件系統(tǒng)發(fā)給Block Layer層的。

1.2 request

request代表塊設(shè)備可以處理的一次任務(wù)單元，一個(gè)request由一個(gè)bio或者多個(gè)扇區(qū)相連的bio組成。

1.3 架構(gòu)圖

1.4 小結(jié)

Block Layer將文件系統(tǒng)提供的bio變成request，然后交給塊設(shè)備驅(qū)動(dòng)處理。

二、2.0版本

目前只支持單個(gè)進(jìn)程訪問塊設(shè)備。為了可以支持多進(jìn)程，我們在塊設(shè)備驅(qū)動(dòng)中創(chuàng)建一個(gè)隊(duì)列：request_queue，所有的進(jìn)程發(fā)起bio生成的request，會(huì)被投遞到request_queue，塊設(shè)備循環(huán)處理request_queue中的request。

2.1 request_queue

每一個(gè)塊設(shè)備都有一個(gè)工作隊(duì)列，request_queue，保存準(zhǔn)備就緒待處理的request。

2.2 架構(gòu)圖

2.3 小結(jié)

這樣子就實(shí)現(xiàn)了多個(gè)進(jìn)程同時(shí)訪問塊設(shè)備，而且在新的一個(gè)bio變成request之前，可以先看看該bio能否合并到request_queue的某個(gè)request，這樣子就可以提升bio處理的效率。

三、3.0版本

好像看起來2.0已經(jīng)挺完美了，但是request_queue會(huì)有一把鎖控制，如果多個(gè)進(jìn)程短時(shí)間發(fā)起多個(gè)bio，多個(gè)進(jìn)程不斷競爭鎖，這樣子性能不是很好，我們就引入了plug。

3.1 plug

plug翻譯成中文就是塞子，每一個(gè)進(jìn)程會(huì)有一個(gè)plug，plug是一個(gè)request的list，先將一個(gè)進(jìn)程短時(shí)間發(fā)起的所有bio生成request先堆積到當(dāng)前進(jìn)程的plug list，然后在等待特定時(shí)機(jī)釋放plug中的requests到request_queue，這樣子可以提升bio處理的效率。

3.2 架構(gòu)圖

3.3 小結(jié)

架構(gòu)越來越完美了，除了上面的流程，在新的一個(gè)bio變成request之前，先看看能不能合并到plug里面的某個(gè)request中，如果不行在，再看看能否合并到request_queue里面的某個(gè)request中，如果不行再變成request，然后放到plug list中，等待積攢一定量之后，統(tǒng)一放置request_queue里面。

四、4.0版本

看起來好像3.0已經(jīng)很完美了，但是我們會(huì)發(fā)現(xiàn)3.0有兩個(gè)明顯的優(yōu)化點(diǎn)。

優(yōu)化點(diǎn)1：

傳統(tǒng)的塊設(shè)備是機(jī)械磁盤，這種硬件是靠一個(gè)磁頭不斷移動(dòng)進(jìn)行訪問數(shù)據(jù)的，如果我們可以把所有request排序，這樣子就可以提升塊設(shè)備的訪問效率。

舉個(gè)例子：一個(gè)外賣員需要送很多外賣到一個(gè)辦公樓，他將外賣按樓層排序合并，然后一層層的送，肯定比隨機(jī)拿一個(gè)外賣，然后一層層的送的速度快。

優(yōu)化點(diǎn)2：

每個(gè)塊設(shè)備單位時(shí)間處理request的次數(shù)是有限的，如果我們可以提升前臺(tái)的進(jìn)程request被處理的優(yōu)先級(jí)，這樣子就可以帶來更好的用戶體驗(yàn)。

4.1 scheduler

翻譯成中文就是調(diào)度器，scheduler就是可以解決上述的兩個(gè)優(yōu)化點(diǎn)，scheduler會(huì)在內(nèi)部創(chuàng)建自定義的各種隊(duì)列來存放plug釋放出來的request，然后scheduler對這個(gè)所有的request進(jìn)行一個(gè)調(diào)度，按照特定的規(guī)則再分發(fā)給request_queue，讓塊設(shè)備處理。

4.2 架構(gòu)圖

4.3 小結(jié)

有了scheduler，我們就可以實(shí)現(xiàn)所有request的重新排序甚至合并，還可以對不同進(jìn)程的request進(jìn)行不同的優(yōu)先級(jí)控制，目前l(fā)inux支持的scheduler有：CFQ，deadline等

5、總結(jié)

學(xué)習(xí)Block Layer層，其實(shí)就是學(xué)習(xí)以上幾個(gè)重要的部分：bio，request，plug，scheduler，request_queue，而且linux的single-queue架構(gòu)就是和4.0版的架構(gòu)差不多，目前手機(jī)上基本采用這個(gè)single-queue的架構(gòu)。

linux目前除了支持single-queue，還支持multi-queue，我就不展開講的，整體的結(jié)構(gòu)很類似。

6、尾巴

整個(gè)流程好像看起來很爽，其實(shí)我們根本沒有關(guān)注過進(jìn)程的調(diào)度，我說的進(jìn)程就是task_struct，多個(gè)進(jìn)程同時(shí)發(fā)送bio，最后將bio變成request送給了scheduler進(jìn)行調(diào)度，這些代碼運(yùn)行在各自的進(jìn)程上，然后scheduler再將request分發(fā)給塊設(shè)備處理這個(gè)又運(yùn)行在另一個(gè)單獨(dú)的進(jìn)程上。如何讓多個(gè)進(jìn)程發(fā)完request之后休眠，如何讓塊設(shè)備驅(qū)動(dòng)處理完之后喚醒這些休眠的進(jìn)程。這個(gè)喚醒的關(guān)鍵點(diǎn)：在于bio結(jié)構(gòu)體中的bio_end_io_t *bi_end_io這個(gè)callback函數(shù)指針。

? 回復(fù)「?籃球的大肚子」進(jìn)入技術(shù)群聊

回復(fù)「1024」獲取1000G學(xué)習(xí)資料

總結(jié)

以上是生活随笔為你收集整理的Linux 块设备，Block Layer层架构演变的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。