羅圣美,陸游游,秦雄軍,楊洪章,張佳程,舒繼武
1(清華大學 計算機科學與技術系,北京 100084)2(中興通訊股份有限公司,南京 210012)
分布式文件系統是高性能計算、互聯網大數據等大規模系統的關鍵組成部分[1].近年來,隨著高性能計算和互聯網大數據系統的規模急劇增長,數據的存儲與處理面臨更嚴峻的挑戰.在分布式文件系統中,元數據服務(Metadata Service)是制約分布式文件系統性能的瓶頸.分布式文件系統數據訪問首先需要向元數據服務器請求文件的元數據描述信息,然后依據所獲得的元數據信息,訪問數據服務器,如高性能計算領域的文件系統Lustre、OrangeFS等均采用類似訪問模式.元數據服務位于數據訪問的關鍵路徑上,元數據的訪問性能直接影響數據的訪問性能,因而,優化元數據操作的性能對分布式文件系統整體性能的提升至關重要.
由于元數據操作具有粒度小、更新頻繁的特點,元數據操作性能一直是分布式文件系統中的設計難點.元數據操作的粒度小,體現為每次操作通常僅僅修改很少的字節,例如inode索引元數據通常修改128字節,甚至只是修改其中一個或僅幾個結構體的字段.元數據操作的另一特點是更新頻繁,體現在同一操作需要更新多個地方,并需要及時寫回持久性介質以保證數據正確性.例如,文件創建操作需要修改文件索引節點、父目錄及父目錄索引節點.這兩個特點使得元數據寫回操作呈現分散隨機寫特征,且數據寫放大問題嚴重,即數據寫回持久性介質的數據量遠大于軟件程序寫入的有效數據.由于固態盤(Solid State Drive,SSD)具有遠高于傳統磁盤的隨機讀寫能力與數據持久性,所以目前通常將SSD作為分布式文件系統元數據服務器的存儲介質,以降低系統訪問的延遲.然而直接在元數據服務器中使用SSD替換硬盤存在幾個問題.SSD的隨機寫性能遠遠低于順序寫與讀性能,因而不能完全發揮SSD的性能優勢.同時,SSD具有磨損問題,即具有有限的寫入量限制.元數據的寫放大問題不僅對系統性能產生嚴重影響,而且加速了閃存的磨損.因而,直接將SSD用于分布式文件系統的元數據加速仍然不能取得理想效果.
本文提出了一種結合SSD特性的分布式文件系統元數據讀寫優化技術,并基于該技術實現了元數據節點的本地文件系統MDSFS.MDSFS基本原理是將要更新的元數據中的臟數據以記錄(record)形式拼接在一起,僅將拼接而成的數據頁寫入物理盤.這樣在每次同步操作時,需要真正落盤的數據量大大減少,不僅降低了寫放大系數,而且減少了同步操作的時間,提升了文件系統寫入性能.元數據寫入具有粒度小,同步頻繁的特點,傳統文件系統在這種環境下寫放大嚴重,且延時較大.MDSFS根據元數據的特點進行優化,元數據寫入粒度越小,同步操作越頻繁,MDSFS表現得比傳統文件系統越有優勢,通過對元數據的優化管理,使得系統免受頻繁小數據同步的沖擊.
分布式文件系統的元數據優化技術可分為兩類:分布式元數據服務優化技術和元數據服務讀寫優化技術.面向SSD存儲設備的本地文件系統在近年來也得到了較大的關注.除了早期的嵌入式閃存文件系統之外,服務器端的通用閃存文件系統也得到了較快發展.
分布式元數據服務優化一直是分布式文件系統中的關注問題.為提高元數據服務性能,不少文件系統采用元數據集群的方式提供元數據服務.如何切分元數據以實現在多元數據節點上的分布與均衡是其中的研究熱點,Ceph文件系統通過動態子樹的方式實現元數據在多節點之間的動態均衡[2].針對大目錄的文件元數據訪問慢的問題,GIGA+將同一目錄劃分為固定長度的目錄分區,并哈希到不同節點,以提高訪問效率[3].文獻[4]進一步提出了動態的兩層分割方法,提供更細粒度的目錄并發與查詢.
為提高元數據性能,分布式文件系統還采用了客戶端緩存、預取等技術.NFS文件系統在第三版本中引入READDIRPLUS命令,在獲取文件句柄的同時傳輸文件屬性,減少了LOOKUP的訪問次數[5].NFS在第四版本中還引入RPC組合(Compounded RPC),即將多個RPC組合到單個RPC中,減少網絡交互次數[6,7].文獻[8]進一步提供了放松順序性,以提高分布式文件系統的操作性能.
近年來,不少研究人員還提出采用鍵值存儲的方式加速文件系統元數據性能.卡內基梅隆大學提出的IndexFS,采用了LevelDB鍵值存儲系統存儲文件系統元數據,大幅提高了元數據性能[9].類似的,XtreemFS文件系統*XtreemFS.http://www.xtreemfs.org/也基于BabuDB[10]實現了基于鍵值存儲的元數據管理.文獻[20]提出了在并行文件系統GPFS、Lustre上,使用SSD作為元數據服務器的存儲介質,以提高元數據操作的帶寬.PLFS[22]將SSD作為磁盤的緩存,以加速分布式文件系統元數據的讀寫.然而,如何在元數據服務器中深度優化SSD以提高元數據性能尚未得到廣泛研究.
分布式文件系統中元數據的組織多以本地文件系統的形式存儲,本地文件系統的讀寫優化直接服務于元數據性能的提升.面向SSD存儲設備的本地文件系統在近年來也得到了較多的關注.除了早期的嵌入式閃存文件系統之外,服務器端的通用閃存文件系統也得到了較快發展.
FusionIO公司與普林斯頓大學的研究人員聯合提出了DFS(Direct File System)文件系統.DFS通過VFSL(Virtualized Flash Storage Layer)實現塊的分配和回收.VFSL是Linux設備驅動和FushionIO的特殊硬件的一個結合*FushionIOioDrive specification sheet.http://www.fusionio.com/PDFs/Fusion%20Specsheet.pdf,向文件系統或數據庫系統提供了一個巨大的線性虛地址空間,隱藏了從虛擬地址到物理頁面之間的映射細節,使得客戶端程序可以更加靈活的方式在單一層面上直接訪問多個閃存設備.DFS利用VFSL進行inode和數據塊的分配與回收,實現了簡單的映射機制,大大簡化了文件系統的設計和實現.與Ext4相比,DFS在direct模式和buffered模式下均有一定的性能提升[11].
對象式閃存系統OFSS(Object-based Flash Storage System)主要是為了解決文件系統寫放大系數過大的問題而提出的[12].OFSS提出了一種基于對象式的閃存轉換層OFTL(Object-based Flash Translation Layer),OFTL能夠以對象存儲方式提供閃存存儲管理功能,實現從對象邏輯操作到閃存物理地址之間的轉換.OFTL向文件系統提供對象式接口(oread,owrite,oflush等).讀寫操作均以字節為粒度進行,可以有效地進行數據的緊湊組織與頁面組合,以減少寫入量,從而減小寫放大系數[13].
文件系統目錄樹更新有分散小寫和頻繁同步兩個特點,導致其一致性與持久性的維護需要極高的代價.分散小寫導致SSD設備性能下降,頻繁同步則導致SSD設備壽命下降.ReconFS[14]通過分離易失性與持久性目錄樹的文件系統命名空間管理機制來降低元數據更新代價,同時ReconFS還提出了嵌入式索引技術,將索引頁面元數據嵌入被索引頁面,來提供目錄樹一致性,減少了數據寫回.
F2Fs*A.B.Bityutskiy.JFFS3 design issues.http://www.linux-mtd.infradead.org, 2005是一個專門針對閃存設備優化過的log-structured文件系統.F2Fs引入了segment,section和zone三種分配單位.為了解決日志型(log-structured)文件系統的雪球式更新的問題,F2Fs引入了node address table,索引塊中不再存放物理地址,而是存放node ID,根據node ID在node address table中查找相應的物理地址.F2Fs中存在六個不同的log區,根據數據的冷熱程度,F2Fs將數據寫入到對應的log區,實現了數據的冷熱分組[15].
ParaFS[16]是一個充分利用閃存設備并發特性的日志型(log-strutured)文件系統.ParaFS提出了一種二維數據分配策略,既保證了數據的冷熱分組不會遭到破壞,又保證了閃存通道(channel)級的并發得到了充分利用.為了保證垃圾回收的有效性,ParaFS將傳統文件系統級的垃圾回收和FTL級的垃圾回收整合到文件系統里,減少了冗余.ParaFS還在文件系統級實現了一個請求調度器,每個調度隊列對應一個channel,ParaFS將新的請求分配到當前負載最小的隊列里.
綜上,這些面向閃存的本地文件系統的研究,有效提高了SSD設備在存儲系統中的利用效率.然而,分布式文件系統中元數據的存儲與本地通用文件系統的存儲呈現不同特征,如何基于分布式文件系統元數據的存儲特征,設計更為高效的組織結構是本文的一個重要研究內容.本文針對元數據細粒度、更新頻繁等特點,研究了內存頁面的重新組織、多次變化數據的迭代更新、元數據寫入方式的進一步優化等內容.
本節主要描述一個基于本地元數據文件系統MDSFS的架構設計,以及結合SSD特征而進行的細粒度元數據更新技術、日志式寫入方式和意外故障恢復關鍵技術.
基于本地元數據文件系統MDSFS的元數據系統架構設計如圖1所示.主要包括客戶端,數據服務器和元數據服務器三部分.MDSFS對元數據的處理流程如圖2所示.

圖1 MDSFS元數據系統架構圖Fig.1 MDSFS′s metadata architecure
MDSFS對元數據的管理分為兩個部分,即內存部分和閃存部分.在閃存部分,MDSFS劃分了兩個區域,一部分是傳統的文件系統映像區,用來存儲持久化的文件系統數據,另一部分是緩沖區,用來存儲更新的元數據記錄.在內存中,除了傳統的頁高速緩存部分,MDSFS還定義了一套專用的數據結構來進行數據標記和管理.

圖2 MDSFS數據流程圖Fig.2 MDSFS′s data flow chart
當分布式文件系統的元數據被更新時,MDSFS的內存管理程序會對寫入的臟數據建立索引,并在同步操作時,將這些小于頁粒度更新的臟數據進行拼接組合,然后將拼接組合后的新數據頁,寫入到閃存的緩沖區中,這樣減少了頻繁的元數據更新所帶來的寫放大問題.當緩沖區的數據達到一定閾值后,MDSFS會對緩沖區中的數據進行檢查點(checkpoint)操作,將這些臟數據寫入到文件系統映像中,完成整個數據持久化的過程.
在分布式文件系統更新元數據的過程中,MDSFS使用記錄級的更新方式,采用基樹索引和位圖標記的方式,詳細記錄數據的更新位置和長度.在數據寫入緩沖區和文件系統映像時,MDSFS采用日志式寫入方式,即所有的數據都寫入新的地址上,這樣便于掉電恢復,有利于保證數據的一致性.
MDSFS以記錄的形式將每個內存頁中臟的部分進行標記和拼接.在記錄級更新方式中,MDSFS記錄所有寫請求中的數據更新范圍.在同步操作發生時,如用戶顯式調用同步操作(fsync,fdatasync等)[17,18],或者操作系統的后臺線程(如pdflush)*Flushing out pdflush.http://lwn.net/Articles/326552啟動回寫操作,文件系統啟動寫回操作寫回臟數據.MDSFS遍歷屬于該文件的所有記錄,將其所指向的頁高速緩存中的臟數據段拼接在一起,組成完整頁面后,再以日志形式順序寫入閃存的緩沖區中.

圖3 記錄(record)組成示意圖Fig.3 Record organization
圖3描述了記錄(Record)的組成結構.每個頁面中的臟數據以變長形式組織,為了描述這些變長數據,MDSFS為每段數據加上了標記其身份的信息元組,該元組以
MDSFS采用變長的形式,以字節為粒度組織最近更新的這部分數據,可能使得讀取最新數據時需要結合文件系統映像和內存數據進行合并更新,導致定位較慢,而專門為這部分數據建立索引開銷較大.為了解決這個問題,MDSFS通過增加臟數據相對應的內存頁面的引用計數,強制將被記錄指向的數據頁保留在文件系統頁高速緩存中.由于記錄中的臟數據為最近更新數據,將其對應的數據頁保留在高速緩存中的命中率較高,因而MDSFS不會影響讀操作的性能.
當寫請求到來時,對于符合預置條件的細粒度元數據更新,MDSFS首先按正常的文件系統路徑更新頁高速緩存,但是并不把內存頁面標記為臟,這是為了防止臟的內存頁被后臺pdflush線程整頁寫回到底層存儲設備中.然后,MDSFS將根據寫請求的長度以及位置信息,建立記錄的四元組
盡管SSD的隨機讀寫性能相比磁盤有了質的提高,但是不能忽視的是,SSD的隨機讀寫性能仍然要遠低于其順序讀寫性能.因此MDSFS以日志更新的形式順序地將拼接后的數據頁寫入SSD盤中,以實現最大的寫入性能.

圖4 MDSFS日志式順序寫入緩沖區Fig.4 MDSFS write jounal to buffers sequencely
圖4中,MDSFS在SSD上劃出固定大小的空間(可配置)專門用于日志式寫入,稱為緩沖區域.緩沖區域不屬于文件系統的地址空間,因而文件系統不能檢索到其中的數據.
當文件的同步操作到來時,首先,MDSFS根據文件的inode號,在內存中找到與該文件相關的記錄;然后遍歷屬于該文件的所有記錄,把每條記錄中data pointer指向的數據段連同記錄信息,拼接到臨時的內存頁面中,當臨時頁面不足以容納一條完整的記錄時,以padding填充頁面剩余部分.之后,MDSFS將臨時頁以日志的形式順序寫入當前緩沖區中進行持久化.重復以上步驟直到所有記錄處理完畢,此時該文件的同步操作完成,該文件的所有臟數據已經寫入到閃存盤的緩沖區域,完成了數據的持久化保證.
綜上所述,對于分布式文件系統元數據細粒度和頻繁更新模式,MDSFS采用記錄級標記方法,讓小于一頁的臟數據拼接在一起,形成一個完整的臟數據記錄.然后將這些拼接后的臟數據記錄以順序的方式寫入緩沖區域,以完成數據持久性要求.該技術能夠大幅度減少分布式文件系統在元數據同步時的寫入數據量,同時,由于寫入的數據是以順序的方式進行寫入,能夠有效利用SSD盤的高速順序讀寫性能,降低了分布式文件系統元數據寫操作的時間.
MDSFS使用兩個技術來保障系統數據的一致性,分別是檢查點(checkpoint)和故障恢復.檢查點是當SSD的緩沖區使用量超過閾值時,將緩沖區中的以記錄形式拼接的臟數據寫回到文件系統的映像中,實現文件系統映像的一致性.故障恢復是保證在故障發生時,MDSFS可以通過SSD緩沖區和文件系統映像區中的數據,進行恢復,保證數據的持久性與文件系統的一致性.
3.4.1 檢查點(checkpoint)
MDSFS將專用的緩沖區域分為兩塊,每塊大小為64MB(可配置).當用戶發出顯式同步操作或者操作系統后臺線程pdflush發出同步請求時,MDSFS均按上節所述的記錄級更新方式將臟的元數據頁進行拼接,以日志形式將拼接記錄順序寫入到當前緩沖區.當前緩沖區域空間即將耗盡時,MDSFS將進行checkpoint操作,將緩沖區中的臟數據頁寫回到SSD盤的文件系統映像區域中.被索引的數據頁面因為引用計數被加一,所以這些數據會被強制保留在內存中,不會被換出,即在checkpoint過程中需要寫回文件系統映像區域內的數據頁都保留在內存中,不需要額外的讀緩沖區操作.這樣能夠加快MDSFS執行checkpoint的時間.在內存數據頁內容已經寫回原地址后,緩沖區域的數據可以被丟棄,清空的緩沖區能夠被重復使用,被保留在頁高速緩存中的數據頁也能夠被釋放.

圖5 MDSFS checkpoint示意圖Fig.5 MDSFS checkpoint
在checkpoint期間到來的所有同步請求,將以日志式更新的方式寫入另一個緩沖區.通過兩個緩沖區的輪流使用,使得后續同步操作不需要停下來等待checkpoint的完成.圖5描述了checkpoint實現過程.
3.4.2 故障恢復
在日志式寫入的更新過程中,如果發生意外故障,導致系統宕機,需要考慮數據的一致性問題.
如果故障發生在非checkpoint期間,MDSFS在恢復時,會讀出當前緩沖區中的所有記錄.對于每條記錄,根據其文件inode號和偏移值,從文件系統映像中讀出對應的數據到頁高速緩存中,注意此時的數據是陳舊的,然后根據緩沖區記錄中的數據對頁高速緩存中的陳舊數據進行更新,并把內存頁面標記為臟.重復以上步驟直到當前緩沖區中的所有記錄處理完畢,最后,調用sync_fs命令,將文件系統頁高速緩存中的所有臟頁持久化,此時整個系統已處于一致的狀態,故障恢復過程結束.
如果故障發生在checkpoint期間,由于checkpoint過程沒有完成,緩沖區中的記錄還沒有被清除,因此MDSFS恢復時,僅需要對緩沖區的記錄重新做一次checkpoint即可.
基于上述技術,本文實現了一個面向SSD的元數據文件系統MDSFS,該系統使用一棵基樹(Radix Tree)和鏈表對所有的更新進行索引,基樹中存儲了被修改的元數據文件的inode號.在每個inode索引節點上,通過一個鏈表來維護該文件的記錄信息.記錄中包含了指向頁高速緩存中相應頁面的指針(data pointer)、在頁面中的偏移值(offset)及數據段長度(length)等關鍵信息.系統實現時,使用鏈表將屬于同一文件的記錄串聯起來,完成對所有臟數據的遍歷,從而加速元數據文件同步操作.
MDSFS中數據結構間的組織關系如圖6所示.

圖6 MDSFS數據結構組織示意圖Fig.6 MDSFS data structure and organization
當寫操作到來時,MDSFS需要在索引基樹(Radix Tree)中登記相應的記錄.首先,以文件的inode號為索引,在索引基樹中找到相應的inode,如果不存在該inode的索引節點,則新建一個該文件的基樹節點.若找到對應的基樹節點,則以寫操作的偏移量,即offset為索引值找到相應的記錄,MDSFS將屬于同一個頁面的記錄進行合并.同時,MDSFS將頁高速緩存中的頁面引用計數加一,強制保留在內存中以供高速讀取.
在寫操作開始時,MDSFS還需要根據本次寫操作的寫入長度進行判斷.如果寫操作的寫入長度小于內存頁面的二分之一,則按照上述流程進行;如果寫入長度大于內存頁面的二分之一,則不再將其封裝成記錄加入到索引基樹中,因為對于過大的數據段進行拼接反而會降低效率.對于寫入長度大于內存頁面一半的寫請求,MDSFS將按照正常文件系統處理寫請求的路徑進行處理,即不對大粒度的寫操作進行拼接寫入.
當同步操作到來時,MDSFS根據被同步文件的inode號在索引基樹中找到相應的inode節點.如上文所述,每個inode節點的所有記錄通過鏈表鏈接在一起.MDSFS順序掃描該鏈表,將每條記錄及其所指向的數據段拷貝到一個頁面中,當該頁面滿時,將其寫入到閃存的緩沖區中進行持久化.重復此過程,直到該鏈表中所有記錄都已經被正確處理.然后,MDSFS從索引基樹上刪除相應的inode節點,因為該文件的所有臟數據都已經持久化到SSD盤上了.
在當前SSD上緩沖區滿時,專門負責checkpoint的后臺線程被喚醒.該線程掃描緩沖區對應的所有記錄,把記錄指向的內存緩存頁面標記為臟,同時將其引用計數減一,最后通過調用VFS的sync_fs接口將所有的臟頁寫回到文件系統映像中.
本節分別在順序寫入和隨機寫入兩種情況下,采用專用測試工具,對Ext4[19]、F2FS[15]和MDSFS三者的寫性能和寫入量分別進行了對比測試,以評估MDSFS對系統性能和SSD使用壽命的影響.該測試工具,是根據實際使用的分布式文件系統的元數據io特征來設計的,測試使用的trace是從分布式文件系統中采集的,可以反映真實的分布式文件系統下的元數據負載特征.同時使用fio測試工具對三者進行了性能對比測試.
實驗在linux 3.0.76內核環境下進行,所用服務器的配置如表1.測試使用的SSD設備容量為400GB.

表1 實驗環境配置Table 1 Configuration of experiment
5.2.1 順序寫性能
表2為順序寫條件下Ext4、F2FS和MDSFS三者性能對比結果.該實驗包含五個文件的寫操作,五個文件分別為DIC,DIRNODE,FENTRYIDX,FENTRY(FNODE),FNODEIDX.這五個文件分別模擬目錄索引、目錄元數據節點、目錄項索引、目錄項元數據(文件元數據節點)、文件元數據節點索引的數據訪問模式.每個文件均包含86400條記錄,每條記錄在這五個文件中的長度分別為30B,50B,60B,70B,4096B,其中30B,50B,60B,70B代表細粒度讀寫,4096B代表粗粒度讀寫的情況.本實驗中,每寫入100條記錄調用一次fsync進行同步,測試結果單位為秒.

表2 順序寫入性能測試Table 2 Benchmark of sequence write
表2數據顯示,在順序寫入情況下,MDSFS在細粒度寫入時,所需時間僅為Ext4的24%~39%.MDSFS所需時間較F2FS也有一定下降.MDSFS的性能優勢主要來源于其記錄級拼接技術,即將數據頁中的臟數據部分進行合并后寫入,減少無效數據的寫入.
在粗粒度寫入時,MDSFS所需時間為Ext4的62%左右,較F2Fs也有一定下降.主要原因是,MDSFS和F2Fs都采用日志式的順序寫入方式,而Ext4采用原地更新的隨機寫入方式.

圖7 順序寫入性能對比Fig.7 Performance comparison of sequence write
圖7是對順序寫入性能的圖形化表示.由圖可見,順序寫入情況下,無論是細粒度的寫入,還是粗粒度的寫入,MDSFS較Ext4均有明顯的性能提升.
5.2.2 順序寫入量
為進一步評估MDSFS對SSD壽命的影響,本實驗對順序寫情形下的寫入量進行采集和評價.
表3顯示了Ext4、F2Fs和MDSFS在順序寫入下的寫入量,其結果以Ext4的寫入量為基礎進行了歸一化表示.在順序寫入的情況下,MDSFS在細粒度寫入時,寫入量是Ext4的31%-46%.這進一步驗證了表2在順序讀寫性能實驗中的結果,即由于記錄級拼接技術大幅降低了細粒度寫回情形下的寫入量,從而提升了數據寫入性能.
MDSFS在粗粒度順序寫入時,寫入量是Ext4的0.98倍.這是因為一方面MDSFS的記錄拼接技術沒有發揮作用,另一方面MDSFS和F2Fs一樣,都是采用日志式寫入,在寫入時不僅要更新數據,還需要更新索引數據,在順序寫情況下,索引數據具有良好的局部性,寫入量較小,因此寫入量和Ext4相差不大.

表3 順序寫入量測試Table 3 Perfoamance of sequence write in different block siz

圖8 順序寫入量對比Fig.8 Comparison of sequence write size
由圖8可知,在細粒度順序寫入的情況下,MDSFS寫入量較Ext4有明顯減少,但在粗粒度情況下,MDSFS寫入量減少不明顯.
5.2.3 隨機寫性能
表4為隨機寫條件下Ext4,F2Fs和MDSFS三者性能對比結果.該實驗所采用數據集與順序讀寫性能測試數據集相同.不同的是,每次寫入的記錄個數是隨機的,記錄之間的間隔也是隨機的,直到一共寫入86400 * 10(循環十次)條記錄后結束.測試結果單位為秒.
表4顯示,在隨機寫入情況下,MDSFS在細粒度寫入時,所需時間僅為Ex4的19%-25%,為F2Fs的28%~56%.主要原因是在細粒度寫入情形下,MDSFS的性能優勢不僅僅來源于其記錄級拼接技術減少了數據寫入量,還源于其記錄級拼接技術中對臟數據合并后的日志式順序寫入.后者在MDSFS與F2FS的結果對比中可以體現出來.F2Fs沒有記錄級拼接技術,數據以整頁4 KB粒度寫回.盡管其采用日志式寫入方式,但由于數據邏輯上隨機,其元數據更新引入較大開銷.而MDSFS將臟數據部分拼接寫回,以記錄粒度順序寫回,無需立刻修改元數據.相比于順序寫入測試,MDSFS比F2Fs性能提升更多.

表4 隨機寫的性能測試Table 4 Random write benchmark
在粗粒度隨機寫入時,MDSFS寫入時間為Ext4的68%,為F2Fs的92%.

圖9 隨機寫入性能對比Fig.9 Comparizon of radom write performance
由圖9可知,在細粒度隨機寫入情況下,MDSFS性能較Ext4和F2Fs有明顯提升.在粗粒度隨機寫入情況下,MDSFS也比Ext4和F2Fs有一定提升,但是,性能提升不及細粒度明顯.
5.2.4 隨機寫入量
表5顯示了Ext4、F2Fs和MDSFS在隨機寫入下的寫入量,其結果以Ext4的寫入量為基礎進行了歸一化表示.在隨機寫入的情況下,MDSFS在細粒度寫入時,寫入量減少達到了90%以上.相比于順序寫入測試,MDSFS在隨機寫入測試的寫入量進一步減少.這是因為在隨機寫入測試中,元數據較為分散,因而數據得到進一步聚合,降低了元數據的寫入量.

表5 隨機寫入量測試Table 5 Perfoamance of sequence write in different block size
MDSFS在粗粒度隨機寫入時,寫入量是Ext4的1.60倍.這是因為MDSFS和F2Fs一樣,采用日志式寫入,在寫入時不僅要更新數據,還需要更新索引數據(也即元數據),但是在隨機寫情況下,元數據比較分散,缺少局部性,對索引數據的寫入量較大所致.
由圖10可知,細粒度隨機寫入的情況下,MDSFS寫入量較Ext4和F2Fs明顯減少.僅在粗粒度隨機寫情況下,MDSFS寫入量比Ext4增大.
5.3.1 fio性能測試
fio*Fio.http://freshmeat.net/projects/fio/是一個I/O測試工具,常用來進行性能測試和壓力測試.fio支持對文件系統和塊設備的直接測試.fio簡單易用,以一種易于理解的文本模式對測試工作進行描述.

圖10 隨機寫入的寫入量對比Fig.10 Comparison of radom write size
本實驗使用fio對MDSFS,Ext4和F2Fs分別進行了隨機寫入性能測試.I/O引擎使用psync方式,測試時間為10分鐘,測試線程10個.
從表6可以看出,使用fio測試情況時,MDSFS寫入速度是Ext4的2.33倍,是F2Fs的1.26倍.對比示意如圖11所示.

表6 fio測試隨機寫入速度測試Table 6 Performance of random write tested by fio
由于fio是通用的存儲系統性能測試工具,本測試說明MDSFS不僅可用于元數據性能優化,同時對于數據塊存儲也會有較好的提升效果.

圖11 fio測試隨機寫入速度對比Fig.11 Comparison of random write in different filesystem
5.3.2 fio寫入量測試
從表7可以看出,在本實驗中使用fio進行測試時,MDSFS寫入量僅為Ext4的73%,為F2Fs的59%.主要原因是,F2Fs采用日志式寫入方式,盡管在性能上體現了優勢,但是放大了寫入量.本文所提MDSFS采用記錄級拼接方式,適合fio測試采用的64B~2048B的細粒度寫入數據,不僅在性能上有優勢,在寫入量上也有一定的比較優勢.

表7 Fio測試隨機寫入量測試Table 7 Performance of amount of radom write tested by fio

圖12 fio寫入量對比Fig.12 Comparisonof write sizein different filesystem
由圖12可以看出,在fio隨機測試情況下,MDSFS寫入量上對比Ext4和F2Fs都有明顯的降低.
在分布式存儲系統中,元數據寫入具有粒度小,同步頻繁的特點.傳統文件系統在這種情況下寫放大非常嚴重,且延時較大.本章介紹了一種基于SSD的元數據讀寫優化的文件系統MDSFS,采用記錄級拼接和日志式寫入方式,以記錄的形式將內存頁中真正臟的數據部分進行標記和拼接,同時在SSD設備上劃出了獨立的緩沖區,在同步操作時,以日志的形式順序寫入到緩沖區中,消除了這一過程中的隨機寫操作,提高了元數據的寫入性能.
測試表明,在細粒度隨機寫情況下,元數據寫入時間較Ext4減少77%,寫入量較Ext4減少94%以上.在細粒度順序寫情況下也有較好的提升效果,但是粗粒度寫情況下,提升效果不明顯.該項技術已應用于中興通訊分布式文件存儲系統中,并在中國移動南方基地云存儲項目中實際使用,有效提升了元數據訪問性能,同時延長了SSD使用壽命.
:
[1] Shvachko K,Kuang H,Radia S,et al.The hadoop distributed file system[C].2010 IEEE 26th Symposium on Mass Storage Systems and Technologies (MSST),IEEE,2010:1-10.
[2] Weil S A,Brandt S A,Miller E L,et al.Ceph:a scalable,high-performance distributed file system[C].Proceedings of the 7th Symposium on Operating Systems Design and Implementation(OSDI),USENIX Association,2006:307-320.
[3] Patil S,Gibson G A.Scale and concurrency of GIGA+:file system directories with millions of files[C].USENIX Conference on File and Storage Technologies(FAST),2011:1-14.
[4] Xing J,Xiong J,Sun N,et al.Adaptive and scalable metadata management to support a trillion files[C].Proceedings of the Conference on High Performance Computing Networking,Storage and Analysis(SC).ACM,2009:1-26.
[5] Pawlowski B,Juszczak C,Staubach P,et al.NFS version 3:design and implementation[C].In Proceedings of USENIX Summer,1994:137-152.
[6] Shepler S,Eisler M,Robinson D,et al.Network file system (NFS)version 4 protocol[EB/OL].http://tools.ietf.org/html/rfc3530,2003.
[7] Goodson G,Welch B,Halevy B,et al.NFSv4 pNFS extensions[EB/OL].http://tools.ietf.org/html/draft-ietf-nfsv4-pnfs-00,2005.
[8] Lu Y,Shu J,Li S,et al.Accelerating distributed updates with asynchronous ordered writes in a parallel file system[C].2012 IEEE International Conference on Cluster Computing (CLUSTER),IEEE,2012:302-310.
[9] Ren K,Zheng Q,Patil S,et al.Indexfs:scaling file system metadata performance with stateless caching and bulk insertion[C].International Conference for High Performance Computing,Networking,Storage and Analysis(SC),IEEE,2014:237-248.
[10] Stender J,Kolbeck B,H?gqvist M,et al.BabuDB:fast and efficient file system metadata storage[C].2010 International Workshop on Storage Network Architecture and Parallel I/Os (SNAPI),IEEE,2010:51-58.
[11] Josephson W K,Bongo L A,Li K,et al.Dfs:a file system for virtualized flash storage[J].ACM Transactions on Storage (TOS),2010,6(3):85-99.
[12] Lu Y,Shu J,Zheng W.Extending the lifetime of flash-based storage through reducing write amplification from file systems[C].USENIX Conference on File and Storage Technologies(FAST),2013,13:257-270.
[13] Boboila S,Desnoyers P.Write endurance in flash drives:measurements and analysis[C].USENIX Conference on File and Storage Technologies(FAST),2010:115-128.
[14] Lu Y,Shu J,Wang W.ReconFS:a reconstructable file system on flash storage[C].USENIX Conference on File and Storage Technologies(FAST),2014,14:75-88.
[15] Lee C,Sim D,Hwang J Y,et al.F2FS:a new file system for flash storage[C].USENIX Conference on File and Storage Technologies(FAST),2015:273-286.
[16] Zhang J,Shu J,Lu Y.ParaFS:a log-structured file system to exploit the internal parallelism of flash devices[C].2016 USENIX Annual Technical Conference (USENIX ATC),USENIX Association,2016:87-100.
[17] Harter T,Dragga C,Vaughn M,et al.A file is not a file:understanding the I/O behavior of apple desktop applications[C].ACM.Proceedings of the 23rd ACM Symposium on Operating Systems Principles(SOSP),ACM,2011:71-83.
[18] Jeong S,Lee K,Lee S,et al.I/O stack optimization for smartphones[C].USENIX Annual Technical Conference(USENIX ATC),2013:309-320.
[19] Mathur A,Cao M,Bhattacharya S,et al.The new ext4 filesystem:current status and future plans[C].Proceedings of the Linux Symposium(OLS),2007,2:21-33.
[20] Alam S R,El-Harake H N,Howard K,et al.Parallel I/O and the metadata wall[C].Proceedings of the Sixth Workshop on Parallel Data Storage(PDSW),ACM,2011:13-18.
[21] Bent J,Grider G,Kettering B,et al.Storage challenges at los alamos national lab[C].2012 IEEE 28th Symposium on Mass Storage Systems and Technologies (MSST),IEEE,2012:1-5.