塊存儲(chǔ)沒(méi)那么神秘！

之前一直跟大家聊文件系統(tǒng)，文件系統(tǒng)提供一層文件到物理塊層的映射轉(zhuǎn)換。這層邏輯可能非常復(fù)雜，依賴(lài)于文件系統(tǒng)的實(shí)現(xiàn)。今天則跟大家聊聊塊層，塊層位于 fs 層之下，大家可能平時(shí)不怎么接觸，看不見(jiàn)摸不著。其實(shí)沒(méi)有那么神秘，來(lái)看下塊設(shè)備的使用姿勢(shì)， Linux 經(jīng)?？匆?jiàn)的 sda，sdb 這樣的盤(pán)符文件其實(shí)就是塊設(shè)備。

我們來(lái)試一下對(duì)一個(gè)塊設(shè)備進(jìn)行讀寫(xiě)（注意，千萬(wàn)找一個(gè)不用的塊設(shè)備，有寫(xiě)操作）：

funcmain(){
  //千萬(wàn)注意：/dev/sdx1 盤(pán)，注意一定是要是不用的新盤(pán)哦。這里有寫(xiě)操作，可千萬(wàn)不要寫(xiě)壞數(shù)據(jù)哦
  f,err:=os.OpenFile("/dev/sdx1",os.O_RDWR,0666)
  iferr!=nil{
    log.Fatalf("err:%v
",err)
  }
  //寫(xiě)
  content:="helloworld"
  _,err=f.WriteAt([]byte(content),0)
  iferr!=nil{
    log.Fatalf("err:%v
",err)
  }
  //讀
  buffer:=make([]byte,len(content))
  n,err:=f.ReadAt(buffer,0)
  iferr!=nil{
    log.Fatalf("err:%v
",err)
  }

  fmt.Printf("content=%s,n=%v
",buffer,n)
}

以上就完成了對(duì)塊設(shè)備的一次讀寫(xiě)，大家看用戶(hù)態(tài)操作一下塊設(shè)備是不是非常簡(jiǎn)單呀。說(shuō)白了，就是把它當(dāng)一個(gè)線(xiàn)性的文件來(lái)使用即可。用戶(hù)態(tài)的文件系統(tǒng)經(jīng)常喜歡這樣去管理塊設(shè)備，來(lái)看一下塊層的架構(gòu)。

塊層架構(gòu)

塊設(shè)備的邏輯集中在 Linux 的塊層子系統(tǒng)中。由于塊設(shè)備有多種的類(lèi)型，并且內(nèi)部關(guān)于不同的場(chǎng)景可能會(huì)有不同的調(diào)度需求，所以它的設(shè)計(jì)也必須滿(mǎn)足一定的抽象，塊層內(nèi)一般分為三層：

• 通用層 ：抽象不同的塊設(shè)備，為上層建立統(tǒng)一的塊設(shè)備模型；
• IO 調(diào)度層 ：IO 請(qǐng)求入隊(duì)、出隊(duì)，并且按照特定的策略去調(diào)度（可配置）；
• 塊設(shè)備驅(qū)動(dòng)層 ：針對(duì)不同的塊設(shè)備類(lèi)型有著不同驅(qū)動(dòng)程序。比如 SCSI 設(shè)備，邏輯設(shè)備等；

聊聊這三層：

• 通用層：給上層一個(gè)叫做 submit_bio 的函數(shù)，并且和上層對(duì)齊的 IO 類(lèi)型叫做 bio ，所有的塊 IO 請(qǐng)求封裝成 bio ，然后通過(guò) submit_bio 遞交即可。這是統(tǒng)一的抽象界面；
• IO 調(diào)度層：無(wú)非就是上層請(qǐng)求怎么入隊(duì)，然后怎么派發(fā)給底層。整體的塊 IO 調(diào)度器叫做電梯，它的架子也是電梯算法的架子，調(diào)度算法允許配置，常見(jiàn)的就是 cfq，deadline，noop 這三種算法；
• 塊設(shè)備驅(qū)動(dòng)層：針對(duì)不同塊設(shè)備的封裝，比如有順序訪(fǎng)問(wèn)的塊設(shè)備，還有隨機(jī)訪(fǎng)問(wèn)的，還有邏輯棧式設(shè)備；

塊層 IO 流程

今天走一小段代碼，省略復(fù)雜邏輯，只擼主干邏輯。

下面涉及到代碼，配合 Linux 3.10.1

塊層的入口是 submit_bio 函數(shù)，上層填裝 bio 結(jié)構(gòu)之后，調(diào)用 submit_bio 遞交到塊層。一切的開(kāi)始都是從這個(gè)函數(shù)。bio 就是塊層和上層約定好的參數(shù)結(jié)構(gòu)。塊層的核心工作就是對(duì)這個(gè)結(jié)構(gòu)做處理，做變形，最終做轉(zhuǎn)發(fā)。

塊設(shè)備的讀寫(xiě)都是通過(guò)這個(gè)接口和參數(shù)來(lái)表達(dá)。來(lái)看一下 submit_bio 的邏輯：

voidsubmit_bio(intrw,structbio*bio)
{
  //打上讀寫(xiě)標(biāo)記
  bio->bi_rw|=rw;
  //...
  //構(gòu)造request
  generic_make_request(bio);
}

一個(gè)小信息：FS 和 塊層交互的是 bio 類(lèi)型，但是塊層內(nèi)部用的是 request 結(jié)構(gòu)，由 bio 轉(zhuǎn)換而來(lái)。

來(lái)看下 generic_make_request 中 實(shí)現(xiàn)：

voidgeneric_make_request(structbio*bio)
{
  //保證make_requst核心的邏輯在同一個(gè)進(jìn)城內(nèi)是串行之行的
  if(current->bio_list){
    bio_list_add(current->bio_list,bio);
    return;
  }

  bio_list_init(&bio_list_on_stack);
  current->bio_list=&bio_list_on_stack;
  //循環(huán)處理bio_list里的內(nèi)容
  do{
    //獲取到該塊設(shè)備的隊(duì)列
    structrequest_queue*q=bdev_get_queue(bio->bi_dev);
    //執(zhí)行make_request_fn回調(diào)
    q->make_request_fn(q,bio);
    bio=bio_list_pop(current->bio_list);
  }while(bio);
  current->bio_list=NULL;
}

塊設(shè)備都會(huì)有個(gè) request_queue 結(jié)構(gòu)體。隊(duì)列這個(gè)很容易理解，用來(lái)掛請(qǐng)求的。排序、合并之后 IO 請(qǐng)求總得放在一個(gè)地方。

上面的核心是 request queue 的 make_request_fn 函數(shù)回調(diào)。合并和排序就是在該函數(shù)中實(shí)現(xiàn)。

思考：make_request_fn 又是什么呢？什么時(shí)候賦值的呢？

其實(shí)是設(shè)備創(chuàng)建之初，初始化結(jié)構(gòu)體的時(shí)候賦值好的。比如 SCSI 設(shè)備，那么 make_request_fn 就是 blk_queue_bio 。

注意：這里我們看到還有一個(gè) request_fn 的回調(diào)，SCSI 設(shè)備是初始化成 scsi_request_fn ，記住這個(gè)，后面會(huì)講。

//分配并初始化一個(gè)scsi設(shè)備
scsi_alloc_sdev
scsi_alloc_queue
//創(chuàng)建、初始化請(qǐng)求隊(duì)列,回調(diào)request_fn
__scsi_alloc_queue(sdev->host,scsi_request_fn);
blk_init_queue
blk_init_queue_node
blk_init_allocated_queue
//回調(diào)make_request_fn
blk_queue_make_request(q,blk_queue_bio);

排序、合并的邏輯則是在 make_request_fn 中完成，也就是 IO 請(qǐng)求入隊(duì)的過(guò)程就完成了。

思考：合并、排序究竟是什么意思？

• 合并：將磁盤(pán)上扇區(qū)連續(xù)的多個(gè)請(qǐng)求合并成一個(gè)，然后作為一個(gè) SCSI 請(qǐng)求命令下發(fā)
• 排序：將多個(gè) IO 請(qǐng)求按照磁盤(pán)扇區(qū)的位置進(jìn)行排序，以便磁頭能夠盡可能的往一個(gè)方向擺動(dòng)

合并和排序在 make_request_fn 中完成。來(lái)看一看調(diào)度器的邏輯：

voidblk_queue_bio(structrequest_queue*q,structbio*bio)
{
  el_ret=elv_merge(q,&req,bio);
  if(el_ret==ELEVATOR_BACK_MERGE){
    //往后合并
  }elseif(el_ret==ELEVATOR_FRONT_MERGE){
    //往前合并
  }

get_rq:
  //沒(méi)合并的新請(qǐng)求走這里

  plug=current->plug
  if(plug){
    list_add_tail(&req->queuelist,&plug->list);
  }else{
    add_acct_request(q,req,where);
    __blk_run_queue(q);
  }
}

elv_merge 會(huì)返回一個(gè)常量來(lái)標(biāo)識(shí)向前或者向后合并。如果是向前或者向后合并，那么返回對(duì)應(yīng)的已經(jīng)存在的 request 結(jié)構(gòu)體。如果是不能合并，那么就創(chuàng)建的一個(gè)新的 request 請(qǐng)求。

思考：IO 請(qǐng)求在 make_request_fn 入隊(duì)，那什么時(shí)候派發(fā)呢？

是通過(guò) request_fn 回調(diào)函數(shù)（往前看，設(shè)備初始化的時(shí)候賦值的）來(lái)處理。SCSI 設(shè)備的 request_fn 回調(diào)是 scsi_request_fn 函數(shù)。函數(shù)中有個(gè) for 循環(huán)，會(huì)按照策略逐個(gè)取出請(qǐng)求，封裝處理一下，然后丟到底層去執(zhí)行 （ 使用 scsi_dispatch_cmd ）。

思考：有沒(méi)有想過(guò)能夠合并和排序的基礎(chǔ)條件是啥？

基礎(chǔ)是：有足夠多的請(qǐng)求。這個(gè)依賴(lài)于 Linux 的一個(gè)叫做蓄流/泄流的機(jī)制（Plugging / Unplugging）。蓄流/泄流什么意思？

Linux 塊層為了增加吞吐能力，對(duì)于來(lái)的請(qǐng)求，并不是立即下發(fā)，而是 hold 一段時(shí)間，攢一會(huì)兒，超時(shí)了或者超閾值了，再一次性處理請(qǐng)求下發(fā)。類(lèi)似于用塞子堵住一下（蓄流）池子，水滿(mǎn)了再拔掉塞子（泄流）。

很容易理解，塊層之所以不將每個(gè)請(qǐng)求都立馬下發(fā)，就是為了實(shí)現(xiàn) IO 的調(diào)度。這種短暫的 hold 請(qǐng)求本質(zhì)上是優(yōu)化的基礎(chǔ)。如果每一個(gè)請(qǐng)求都不聚合，不把大家聚在一起，那么是無(wú)法找到優(yōu)化的時(shí)機(jī)的。

request 的派發(fā)邏輯則是在 request_fn 中完成，SCSI 是 scsi_request_fn 函數(shù)。Unplug 的時(shí)候就會(huì)走到這里來(lái)。

staticvoidscsi_request_fn(structrequest_queue*q)
{
  for(;;){
    //按照IO調(diào)度策略取請(qǐng)求出來(lái)
    req=blk_peek_request(q);

    //派發(fā)命令到SCSI驅(qū)動(dòng)層
    rtn=scsi_dispatch_cmd(cmd);
  }
}

這里的邏輯則是集中在 ”怎么取請(qǐng)求出來(lái)？“ 。

IO 調(diào)度算法的主要發(fā)揮時(shí)機(jī)就是在這里?。ㄟ€有一個(gè)時(shí)機(jī)就是入隊(duì)的時(shí)候）

把 request 選出來(lái)之后，封裝成 scsi cmd 命令，通過(guò) scsi_dispatch_cmd 函數(shù)下發(fā)到 SCSI 驅(qū)動(dòng)層即可。這樣一個(gè)請(qǐng)求的派發(fā)就算完成了。

塊層 IO 調(diào)度器

接著上面，聊聊塊層 IO 調(diào)度器。首先塊層整體的 IO 調(diào)度器是一個(gè)電梯算法的架子，你會(huì)發(fā)現(xiàn) elevator 的縮寫(xiě)到處都是。隨著 Linux 系統(tǒng)的持續(xù)發(fā)展還是衍生了不同于真正簡(jiǎn)單電梯算法的調(diào)度算法。這個(gè)就是我們常見(jiàn)的 noop，deadline，cfq 等算法。這部分則是被抽象成一個(gè)界面，可以讓用戶(hù)來(lái)配置選擇。這個(gè)統(tǒng)一界面類(lèi)型叫做 elevator_type ：

structelevator_type{
  //最重要的是這個(gè)
  structelevator_opsops;
}

最重要就是 ops 字段，以 noop 算法為例：

staticstructelevator_typeelevator_noop={
  .ops={
    .elevator_merge_req_fn=noop_merged_requests,
    .elevator_dispatch_fn=noop_dispatch,
    .elevator_add_req_fn=noop_add_request,
    .elevator_former_req_fn=noop_former_request,
    .elevator_latter_req_fn=noop_latter_request,
    .elevator_init_fn=noop_init_queue,
    .elevator_exit_fn=noop_exit_queue,
  }
  .elevator_name="noop",
  .elevator_owner=THIS_MODULE,
}

也就是說(shuō)，不同的調(diào)度算法只要實(shí)現(xiàn)了這個(gè) elevator_type ，就可以在"電梯"的大框架里運(yùn)行了。所以，其實(shí)“電梯”已經(jīng)不是“電梯”了。

調(diào)度算法主要做好兩個(gè)事情：

1. bio 請(qǐng)求入隊(duì)：合并、排序？隨你。比如 noop 就沒(méi)有合并和排序
2. request 請(qǐng)求出隊(duì)：電梯不電梯？隨你，目前就看 deadline 是變形的“電梯”。

調(diào)度算法的實(shí)現(xiàn)在：

• noop 的實(shí)現(xiàn)在 block/noop-iosched.c ，及其簡(jiǎn)單
• deadline 的實(shí)現(xiàn)在 block/deadline-iosched.c ，主要加了一個(gè)超時(shí)，饑餓的考慮
• cfq 的實(shí)現(xiàn)在 block/cfq-iosched.c ，號(hào)稱(chēng)絕對(duì)公平算法，考慮到不同進(jìn)程的性能公平，邏輯是最復(fù)雜的

今天先不給大家展開(kāi)調(diào)度策略的實(shí)現(xiàn)，只簡(jiǎn)要梳理其作用。說(shuō)白了，無(wú)論哪種調(diào)度策略，都只是選出一個(gè) request 出來(lái)而已。

思考：linux 怎么查看調(diào)度策略？

cat/sys/block/{塊設(shè)備符}/queue/scheduler

它自身不帶任何邏輯。沒(méi)有合并、排序。請(qǐng)求按照 fifo 的方式入隊(duì)出隊(duì)。誰(shuí)先進(jìn)的誰(shuí)先出，不區(qū)分請(qǐng)求。

這種簡(jiǎn)單的算法，反而適用于超高性能的介質(zhì)，比如 ssd ，因?yàn)?ssd 的性能已經(jīng)足夠高了，自身提供的并發(fā)能力也是夠的。不需要上層做順序化，批量化，它沒(méi)有磁頭擺動(dòng)的問(wèn)題。合并和排序等多余的邏輯對(duì)它來(lái)講就是累贅。

最像電梯算法的 IO 調(diào)度算法。在電梯算法的基礎(chǔ)上，再加上請(qǐng)求超時(shí)的考慮，起到防止饑餓請(qǐng)求的作用。它內(nèi)部有兩部電梯：讀寫(xiě)。讀請(qǐng)求優(yōu)先，但也會(huì)考慮寫(xiě)?zhàn)囸I，同一時(shí)間只有一部電梯在運(yùn)行。

完全公平隊(duì)列，為每個(gè)進(jìn)程單獨(dú)創(chuàng)建一個(gè)隊(duì)列來(lái)管理該進(jìn)程所產(chǎn)生的請(qǐng)求，試圖給不同的進(jìn)程分配相同的塊設(shè)備使用時(shí)間片，以此來(lái)保證每個(gè)進(jìn)程都能被很好的分配到 IO 帶寬。該算法就屬于萬(wàn)金油，通用場(chǎng)景用它是最保險(xiǎn)的，是最通用的 IO 調(diào)度算法。它的邏輯實(shí)現(xiàn)也是最復(fù)雜的。noop 100 行代碼，deadline 460 行，cfq 4600 行代碼，由此可見(jiàn)。

總結(jié)

• submit_bio 是塊層的統(tǒng)一接口函數(shù)，bio 是統(tǒng)一 IO 結(jié)構(gòu)體
• request 是塊層內(nèi)部的 IO 請(qǐng)求的結(jié)構(gòu)體，bio 到 request 有一層轉(zhuǎn)換，這層轉(zhuǎn)換就是排序、合并的時(shí)候；
• make_request_fn 就是 bio 轉(zhuǎn)換成 request 的時(shí)機(jī)，IO 的排序、合并時(shí)機(jī)就在于此；
• request_fn 是 request 派發(fā)的時(shí)機(jī)，IO 的調(diào)度算法也在此發(fā)揮作用。從 request 隊(duì)列中按照策略選一個(gè) req 出來(lái)，封裝成底層想要的樣子，下發(fā)下去
• IO 調(diào)度器合并、排序，包括按照電梯直上直下派發(fā)請(qǐng)求的目的是減少磁盤(pán)尋址時(shí)間，從而提高整體性能；
• noop，cfq，deadline 三種派發(fā)請(qǐng)求的算法都有適用自己的場(chǎng)景。noop 是幾乎 bypass 請(qǐng)求，沒(méi)有重拍、合并。deadline 是電梯算法衍生了一下。cfq 是全新的一種公平算法，跟電梯沒(méi)啥關(guān)系；
• 塊層最核心的邏輯是：bio 請(qǐng)求怎么入隊(duì)，request 請(qǐng)求怎么出隊(duì)而已，它遠(yuǎn)比文件系統(tǒng)要簡(jiǎn)單；