本期和大家聊的是剛剛在2月份拿到FAST 2018最佳論文獎(jiǎng)的一篇文章。它討論了實(shí)現(xiàn)一種支持保序IO操作的設(shè)備會(huì)帶來(lái)哪些好處，目前的Linux內(nèi)核里處理FLUSH、FUA的方式可以參見 https://lwn.net/Articles/400541/ 

作者

朱延海，Linux系統(tǒng)工程師，來(lái)自阿里云系統(tǒng)組。

阿里云系統(tǒng)團(tuán)隊(duì)，是由原淘寶內(nèi)核組擴(kuò)建而成，2013年淘寶內(nèi)核組響應(yīng)阿里巴巴集團(tuán)的號(hào)召，整建制轉(zhuǎn)入阿里云，開始為云計(jì)算底層系統(tǒng)構(gòu)建完善的系統(tǒng)支持。 阿里云系統(tǒng)團(tuán)隊(duì)是由一群具有高度使命感和自我追求的內(nèi)核開發(fā)人員組成，團(tuán)隊(duì)中的大多數(shù)人，都是活躍的社區(qū)內(nèi)核開發(fā)人員。目前的工作領(lǐng)域主要涉及（但不限于） Linux內(nèi)核的內(nèi)存管理、文件系統(tǒng)、網(wǎng)絡(luò)和內(nèi)核維護(hù)構(gòu)建，以及和內(nèi)核相關(guān)聯(lián)的用戶態(tài)庫(kù)和工具。如果你對(duì)我們的工作很感興趣，歡迎加入我們，請(qǐng)將簡(jiǎn)歷發(fā)送至 tao.ma at linux.alibaba.com或者 boyu.mt at alibaba-inc.com。

概述

現(xiàn)代高速Flash設(shè)備的性能訣竅在于充分提高請(qǐng)求處理的并行度（scale-out），而并非無(wú)限地降低其延遲（scale-up）—例如，使用多通道控制器（multi-channel controllers）、更大的緩存以及更深的命令隊(duì)列，這些都是用來(lái)提高并行度的有效辦法。同時(shí)，寫一個(gè)flash cell所需要的時(shí)間一直沒有什么變化，近來(lái)甚至有變差的趨勢(shì)。在大部分情況下，用戶對(duì)此并不在意，也感覺不到—除非你的應(yīng)用希望它發(fā)出的一系列請(qǐng)求是保序的（guarantee ordering），這也就是本文所要重點(diǎn)討論的問題：

“在目前的設(shè)備上，為請(qǐng)求保序是通過一種代價(jià)很高的辦法來(lái)實(shí)現(xiàn)的：把排在請(qǐng)求X前邊的所有請(qǐng)求都發(fā)出去，然后等待它們?nèi)客瓿?、持久化并返回，然后才發(fā)射請(qǐng)求X，這時(shí)我們就可以說(shuō)X前邊的請(qǐng)求和X之間建立了明確的先后順序關(guān)系。我們把這種機(jī)制叫做Transfer-and-Flush。”

顯而易見，當(dāng)你使用Transfer-and-Flush機(jī)制時(shí)，設(shè)備的并行度會(huì)大大降低，因此帶來(lái)最終性能的降低，設(shè)備越是依賴高并行度來(lái)攫取性能，這種做法就越是令人無(wú)法接受。例如，在一個(gè)智能手機(jī)的單通道SSD上，保序?qū)懻?qǐng)求的IOPS是無(wú)序?qū)懻?qǐng)求的20%，對(duì)于32通道SSD，這一比例降低至1%。在目前的Linux內(nèi)核中，文件系統(tǒng)若真的想執(zhí)行一系列保序請(qǐng)求，使用的機(jī)制也是Transfer-and-Flush。然而，通過Transfer-and-Flush來(lái)保序顯然殺傷力過大了：首先，也許文件系統(tǒng)原本只想讓兩個(gè)單個(gè)請(qǐng)求之間是有序的，但卻不得不使得由flush分隔的兩組操作集合之間變得有序，而這每一個(gè)集合里都可能包含了大量不需要保序的請(qǐng)求；其次，這么做不僅實(shí)現(xiàn)了保序，同時(shí)還提供了同步的持久化保證，這并不是保序想要的—當(dāng)一個(gè)上層應(yīng)用發(fā)出兩個(gè)保序的請(qǐng)求A1和A2時(shí)，它對(duì)于A1和A2具體何時(shí)被持久化并沒有什么期待，可以是異步的，它唯一的要求是一但持久化動(dòng)作開始，A1的持久化必須發(fā)生在A2之前。

本文的作者提出了一種被稱為Barrier-enabled IO stack的方案，這一方案不依賴Transfer-and-Flush，文件系統(tǒng)也就無(wú)需停下來(lái)等待前邊的請(qǐng)求成功返回。這一方案得到的性能提升相當(dāng)驚人：

“SQlite服務(wù)器場(chǎng)景性能提升270%，手機(jī)場(chǎng)景性能提升75%；實(shí)現(xiàn)了Barrier-enabled IO stack的BarrierFS在MySQL場(chǎng)景性能指標(biāo)是EXT4的43倍，在SQLite場(chǎng)景性能指標(biāo)是EXT4的73倍”

下邊我們來(lái)介紹下作者的方案

我們知道，現(xiàn)代IO stack天生就是亂序的。試想文件系統(tǒng)發(fā)射出來(lái)的一簇請(qǐng)求在下邊的路徑里會(huì)經(jīng)歷些什么：

IO調(diào)度器會(huì)對(duì)請(qǐng)求重排列，還有可能合并請(qǐng)求

設(shè)備上的控制器收到請(qǐng)求后放到自己內(nèi)部的命令隊(duì)列里，這時(shí)它也可以隨意改變請(qǐng)求順序。設(shè)備內(nèi)部的錯(cuò)誤、超時(shí)、重傳等等也都有可能對(duì)請(qǐng)求實(shí)際執(zhí)行的順序產(chǎn)生影響

現(xiàn)代設(shè)備內(nèi)部通常也像文件系統(tǒng)一樣，有數(shù)據(jù)塊和元數(shù)據(jù)塊，有自己的journal。請(qǐng)求抵達(dá)存儲(chǔ)設(shè)備內(nèi)部之后，最終對(duì)用戶可見、對(duì)用戶有意義的持久化“順序”不光是由數(shù)據(jù)塊的持久化順序決定，同時(shí)也受那些元數(shù)據(jù)的持久化順序影響，而這兩者并不一定是相同的。

因此，多數(shù)操作系統(tǒng)的IO stack都包含了一個(gè)從硬盤時(shí)代流傳下來(lái)的設(shè)計(jì)假設(shè)：上位機(jī)不能控制持久化順序

“現(xiàn)代IO stack設(shè)計(jì)中的一個(gè)基本假設(shè)就是上位機(jī)不能真正地控制到數(shù)據(jù)的持久化順序”

因此，一但上位機(jī)確實(shí)需要控制持久化順序時(shí)，就只能使用昂貴的Transfer-and-Flush機(jī)制了：如果請(qǐng)求a需要排在請(qǐng)求b之前完成，那么把請(qǐng)求a發(fā)到存儲(chǔ)設(shè)備之后，上位機(jī)就首先需要等設(shè)備報(bào)告a徹底完成，然后發(fā)一個(gè)flush命令并等待flush完成（以防設(shè)備上的cache造成亂序），然后才發(fā)請(qǐng)求b。

以EXT4的默認(rèn)工作模式Ordered模式為例，當(dāng)它提交一個(gè)journal transaction時(shí)，它需要執(zhí)行兩次寫：第一次寫journal descriptor和log blocks（JD），第二次寫commit block（JC）。JD必須先于JC完成持久化。在transaction的層面上看，各個(gè)transaction之間也必須是有序的，排在前邊的transaction一定要比排在后邊的transaction先完成持久化，否則文件系統(tǒng)執(zhí)行故障恢復(fù)時(shí)就有崩潰的可能。 為了把保序語(yǔ)義引入IO stack，作者顯然需要自底向上把這個(gè)語(yǔ)義貫穿到整個(gè)IO stack中去。下邊具體介紹一下作者的工作。

帶barrier的保序塊設(shè)備

“給設(shè)備加入barrier指令支持后，上位機(jī)就不再需要通過顯式地刷cache來(lái)保證請(qǐng)求順序了。當(dāng)設(shè)備收到barrier指令時(shí)，它會(huì)確保排在barrier前的所有指令—可能是寫也可能是讀—都執(zhí)行完畢、完成數(shù)據(jù)傳輸后，才開始執(zhí)行排在barrier后邊的指令。”

論文的作者把他提出的這種barrier實(shí)現(xiàn)成了SCSI命令的一個(gè)附加屬性，而不是一條獨(dú)立的SCSI命令。設(shè)備具體實(shí)現(xiàn)barrier支持的方法有很多，對(duì)于本身已經(jīng)帶有一個(gè)大電容，寫操作返回時(shí)就可以保證持久化的那些設(shè)備，可以認(rèn)為它們天生對(duì)于收到的寫請(qǐng)求就是保序的，因此只要在設(shè)備上邊的各個(gè)層次能夠保證提交順序，整條鏈路就直接可以做出保序的承諾，因此對(duì)于這些設(shè)備沒什么需要修改的。對(duì)于其他設(shè)備，在設(shè)備內(nèi)部實(shí)現(xiàn)保序其實(shí)和之前在整個(gè)IO stack上實(shí)現(xiàn)保序的邏輯基本是一樣的，要么確保writeback cache按順序回寫、要么在回寫時(shí)引入事務(wù)機(jī)制、要么實(shí)現(xiàn)按順序recovery。論文對(duì)于具體如何實(shí)現(xiàn)這種帶barrier支持的存儲(chǔ)設(shè)備一筆帶過，并表示這不是重點(diǎn)，作者認(rèn)為論文的重點(diǎn)在于說(shuō)明一但擁有此種設(shè)備會(huì)帶來(lái)多大好處，至于如何實(shí)現(xiàn)這種設(shè)備那是純粹的engineering efforts，不再過多考慮。

總之，一但擁有這種設(shè)備，就可以實(shí)現(xiàn)請(qǐng)求的保序發(fā)送：

“保序發(fā)送是本文的重要?jiǎng)?chuàng)新之處，上層的文件系統(tǒng)對(duì)于需要保序的請(qǐng)求可以帶上barrier標(biāo)志，只要注意在發(fā)送時(shí)不把它們重排序就行，不再需要等待flush。由下邊的存儲(chǔ)設(shè)備來(lái)保證帶barrier標(biāo)志請(qǐng)求的持久化順序與它們的發(fā)送順序相同。我們把這種機(jī)制叫做wait-on-dispatch”

顯然，wait-on-dispatch比wait-on-transfer的成本要小很多，如下圖所示：

scsi layer

我們沿著從下往上的方向繼續(xù)向上層走，當(dāng)設(shè)備實(shí)現(xiàn)了barrier支持之后，緊接著需要修改的是scsi層。在這里作者利用了scsi層已有的command priority level機(jī)制，按照scsi規(guī)范，命令可以分成三種：head of the queue（收到命令時(shí)要把它插入到隊(duì)列頭上）、ordered（收到命令時(shí)要把它插入到隊(duì)列尾部）、simple（命令可以插入到隊(duì)列中任意位置，但不能放在head of the queue命令或ordered命令的前邊）。因此，只需要把barrier命令打上ordered屬性發(fā)送，把其他寫請(qǐng)求打上simple屬性發(fā)送，就天然地可以在scsi層上保證barrier語(yǔ)義了。

“在目前的塊設(shè)備層實(shí)現(xiàn)中，ordered命令很少使用，這是因?yàn)楫?dāng)整個(gè)IO stack尚且不能做到保序發(fā)送時(shí)，單獨(dú)在scsi層控制命令的發(fā)送順序沒有什么意義。然而，當(dāng)我們?cè)谌窂缴弦隻arrier語(yǔ)義后，scsi層的ordered命令就開始扮演重要的角色了”

epoch-based IO scheduler

在解決了scsi層的問題后，作者沿著IO路徑繼續(xù)往上走，對(duì)IO調(diào)度器加以修改，引入了所謂的epoch-based scheduling：

需要保序的寫操作，帶有REQ_ORDERED標(biāo)志

一對(duì)REQ_BARRIER之間的所有RED_ORDERED寫構(gòu)成一個(gè)epoch

兩個(gè)epoch之間整體上的提交是保序的，即第一個(gè)epoch的所有寫請(qǐng)求提交結(jié)束后，才提交第二個(gè)epoch里的寫請(qǐng)求

一個(gè)epoch內(nèi)部的REQ_ORDERED寫之間可以自由重排序

不帶REQ_ORDERED的寫請(qǐng)求可以任意自由跨epoch重排序

這樣作者就進(jìn)一步解決了barrier殺傷力過大的問題—只有明確表示需要保序的寫請(qǐng)求，其提交順序才受barrier約束。

Barrier-enabled filesystem

IO調(diào)度器理順之后，作者繼續(xù)向上走，開始修改文件系統(tǒng)，提出了barrier-enabled filesystem（BFS）的概念，BFS引入了兩個(gè)新的原語(yǔ)：fbarrier()和fdatabarrier()，它們分別是fsync()和fdatasyn()在保序這個(gè)意義上的對(duì)應(yīng)產(chǎn)物，即是說(shuō)，當(dāng)你調(diào)用它們時(shí)，它們會(huì)確保排在調(diào)用點(diǎn)之前的所有寫操作（或者所有數(shù)據(jù)寫操作）一定比排在它們之后的所有寫操作先完成持久化，然而對(duì)于具體何時(shí)會(huì)完成持久化不做保證。另外，作者也修改了ext4的journal以使它利用上新的barrier機(jī)制：

“利用底層設(shè)備提供的保序語(yǔ)義，我們就可以把一次journal提交過程中的控制平面活動(dòng)（寫請(qǐng)求的提交）和數(shù)據(jù)平面活動(dòng)（數(shù)據(jù)及journal的持久化）分開處理，我們建立兩個(gè)線程，一個(gè)負(fù)責(zé)保序提交請(qǐng)求，另一個(gè)負(fù)責(zé)等待它們完成。我們把這種機(jī)制叫做Dual Mode Journaling”

效果評(píng)估

原文中的第6小節(jié)也包括了塊設(shè)備層和文件系統(tǒng)層的性能測(cè)試，不過我們這里直接關(guān)注最終的應(yīng)用性能提升。

對(duì)于服務(wù)器負(fù)載，作者跑了varmail（varmail發(fā)的fsync非常多），還有MySQL上的OLTP-insert測(cè)試。作者把這里的對(duì)比測(cè)試細(xì)分成了兩種情況，第一種是所謂的durability guarantee測(cè)試，在這個(gè)測(cè)試?yán)飸?yīng)用代碼完全不改，用BarrierFS和標(biāo)準(zhǔn)的EXT4做對(duì)比，這是為了說(shuō)明利用了barrier語(yǔ)義后fsync()本身的性能提升；第二種是所謂的ordering guarantee測(cè)試，在這個(gè)測(cè)試?yán)镒髡吲芰薆arrierFS、OptFS和EXT4三種文件系統(tǒng)（前兩種支持barrier語(yǔ)義），并在前兩種文件系統(tǒng)上把應(yīng)用的fsync()換成fdatabarrier()和osync()（osync是OptFS里的barrier操作），對(duì)于EXT4則加上nobarrier參數(shù)。這一測(cè)試是為了說(shuō)明wait-on-dispatch比wait-on-transfer的優(yōu)越之處，注意這里作者實(shí)際上做了一個(gè)不切實(shí)際的假定，須知有時(shí)應(yīng)用調(diào)用fsync()時(shí)確實(shí)是想保證其持久性的，并非每一處fsync()都可以換成fdatabarrier()，具體要如何修改應(yīng)用必須結(jié)合應(yīng)用的具體上下文。第二個(gè)測(cè)試的結(jié)果只能說(shuō)明結(jié)合應(yīng)用具體場(chǎng)景，去掉overkill的持久化約束后性能提升的上限會(huì)是多少。

在durability guarantee測(cè)試中，BarrierFS為varmail帶來(lái)了10%-60%的性能提升，為MySQL帶來(lái)了12%的性能提升；在ordering guarantee測(cè)試中，BarrierFS帶來(lái)了36倍性能提升，為MySQL帶來(lái)了43倍性能提升。

對(duì)于移動(dòng)設(shè)備負(fù)載，作者測(cè)試了Sqlite，durability guarantee帶來(lái)了75%性能提升，ordering guarantee帶來(lái)了2.8倍性能提升。

結(jié)語(yǔ)

“為高并發(fā)Flash設(shè)備設(shè)計(jì)一個(gè)支持barrier語(yǔ)義的IO stack會(huì)帶來(lái)極大的性能優(yōu)勢(shì) …… 這種barrier語(yǔ)義已經(jīng)日漸成為一種必須品，我們建議從移動(dòng)端到服務(wù)端的各種Flash設(shè)備廠商考慮支持barrier語(yǔ)義”