只讀壓縮文件系統(tǒng)EROFS的設(shè)計與實現(xiàn)

本工作來自上海交通大學(xué)/華為陳海波老師團隊，發(fā)表于ATC 2019。

01動機及背景

EROFS是一個針對移動設(shè)備的只讀壓縮文件系統(tǒng)。作者觀察到，當前手機配備的存儲空間不大，而安卓系統(tǒng)的系統(tǒng)分區(qū)、各種app占用的空間越來越大。導(dǎo)致用戶的實際可支配空間越來越小。如圖所示，安卓系統(tǒng)的/system分區(qū)從2.3.6的184MB增長到了9.0.0的1.9GB。為了盡可能增加用戶的可用空間，對系統(tǒng)分區(qū)使用壓縮文件系統(tǒng)是最優(yōu)解。

文章對比了兩個最常見的壓縮文件系統(tǒng)，Btrfs和Squashfs。其中，Btrfs是一個B樹文件系統(tǒng)，在使能壓縮功能后，文件數(shù)據(jù)每128KB進行壓縮存儲，由于Btrfs是一個通用文件系統(tǒng)，同時支持讀寫功能，因此為數(shù)據(jù)修改效率妥協(xié)了數(shù)據(jù)壓縮率，且在數(shù)據(jù)解壓時會占用大量的內(nèi)存空間。

Squashfs是一個只讀壓縮文件系統(tǒng)，壓縮塊大小4KB-1MB可調(diào)，由于安卓的/system分區(qū)幾乎不需要修改的特性，只讀文件系統(tǒng)比Btrfs更合適。然而，Squashfs同樣存在嚴重的問題，在解壓過程中squashfs會產(chǎn)生大量的CPU和內(nèi)存開銷，在資源緊張的移動設(shè)備上性能下降嚴重。

為了研究squashfs性能下降的原因，文章進行了進一步分析。第一個原因是壓縮輸入塊大小固定，導(dǎo)致了的壓縮輸出數(shù)據(jù)大小不同，因此導(dǎo)致了可觀的讀放大，如下圖所示，以128K壓縮輸入大小為例，壓縮后數(shù)據(jù)存放在SSD的blk1-blk7中，若要讀取4KB數(shù)據(jù)，則需要首先讀取blk1-blk7共7塊，解壓得到128K原始數(shù)據(jù)后，只取其中4KB所需數(shù)據(jù)，這就導(dǎo)致了7倍的讀放大。

第二個原因是在解壓過程中大量的內(nèi)存占用和數(shù)據(jù)搬運開銷，在解壓過程中，squashfs需要大量的臨時內(nèi)存用于解壓，另外，解壓過程中，數(shù)據(jù)需要多次搬運，造成大量的CPU開銷。

這兩個缺陷引出了兩個關(guān)鍵思考：如何在減小讀放大的同時盡可能少的降低壓縮率？如何在解壓過程中盡可能少占用內(nèi)存？

02EROFS的設(shè)計與實現(xiàn)

固定壓縮輸出塊大小

為了產(chǎn)生固定大小的壓縮輸出塊，EROFS在生成鏡像時使用滑動窗口法調(diào)整壓縮算法輸入的原始數(shù)據(jù)大小。固定輸出塊大小具有多種優(yōu)點。首先，固定輸出塊大小壓縮率更高；第二，讀取數(shù)據(jù)時僅需要讀取包含目標數(shù)據(jù)的塊，也就是說一塊數(shù)據(jù)最多僅需要兩次讀操作，相較squashfs，讀放大顯著縮小。

靈活的原始數(shù)據(jù)存儲

在實際解壓前，EROFS可以使用兩種方式存放原始壓縮數(shù)據(jù)。當數(shù)據(jù)僅部分解壓時，EROFS使用緩存式IO，即在發(fā)送讀請求前為申請一塊特殊inode的頁緩存，并將原始壓縮數(shù)據(jù)讀入這一塊緩存中，當再次觸發(fā)讀請求并且讀區(qū)域正好落入當前壓縮塊時，即可省去一次IO。若壓縮數(shù)據(jù)需要全部解壓，EROFS則使用在位IO方式，即將原始壓縮數(shù)據(jù)直接讀入VFS分配的存放解壓后數(shù)據(jù)的頁緩存中。

多種解壓策略結(jié)合

EROFS設(shè)計了四種解壓后數(shù)據(jù)的存放方式。

1.Vmap存放，即使用vmap方法將申請的臨時緩存和VFS分配的緩存作為連續(xù)的虛擬地址作為解壓的目標地址。這種方式有兩個缺點：第一需要動態(tài)申請內(nèi)存，增加內(nèi)存壓力；第二每次解壓都使用vmap和vunmap效率低下。

2. Per-CPU緩沖存放，即使用提前為每個CPU分配的緩存作為解壓數(shù)據(jù)的存放地址，這種解壓方式僅在解壓數(shù)據(jù)小于4頁時使用。

3.滾動存放，即使用EROFS預(yù)先申請的16物理頁內(nèi)存存放解壓數(shù)據(jù)，當解壓數(shù)據(jù)超出16頁時，則滾動回第0頁覆蓋其數(shù)據(jù)繼續(xù)解壓。

4.在位解壓，即解壓后的數(shù)據(jù)和原始壓縮數(shù)據(jù)放置在同一段內(nèi)存空間，這種解壓方式僅在確定解壓過程中不會出現(xiàn)解壓后數(shù)據(jù)覆蓋還未解壓數(shù)據(jù)時才可以使用（在mkfs時會判斷是否會覆蓋，并記錄在inode中）。

根據(jù)四種不同解壓后數(shù)據(jù)存放方式的特點，設(shè)計解壓策略如下圖所示。

03優(yōu)化

索引優(yōu)化：一個壓縮塊中可能存在數(shù)百頁原始數(shù)據(jù)，在解壓時這些頁的索引會占據(jù)大量內(nèi)存，因此若VFS分配的頁中存在多余的可重用頁，則將壓縮塊存儲在可重用頁，這樣可以避免重復(fù)讀取，同時減少內(nèi)存占用。

調(diào)度優(yōu)化：傳統(tǒng)壓縮文件系統(tǒng)如Btrfs使用一個獨立的解壓線程進行數(shù)據(jù)解壓，這樣會帶來調(diào)度開銷，EROFS將解壓工作放在讀者線程執(zhí)行，以避免解壓線程的調(diào)度開銷。

協(xié)同解壓：若多個線程的讀取落入同一個壓縮塊內(nèi)，則僅由一個線程解壓一次，其余線程共用數(shù)據(jù)，避免重復(fù)解壓。

鏡像補?。菏褂迷隽垦a丁方式，EROFS可以支持少量補丁存在。在文件讀取時，EROFS先讀取鏡像內(nèi)文件原本內(nèi)容，再讀取補丁中覆蓋內(nèi)容進行更新。

04評估

評估平臺使用了hikey960開發(fā)板。評估方式采用了fio和enwik9數(shù)據(jù)集，fio分別執(zhí)行順序讀取、隨機讀取、條帶讀?。?28KB讀取4KB）進行基準測試。

測試結(jié)果如下圖所示，在壓縮文件系統(tǒng)中，btrfs表現(xiàn)最差，在每次讀取無法落入緩沖的條帶讀取測試中，squashfs-128K下降明顯，而EROFS的性能與squashfs-4K類似，接近非壓縮的ext4和f2fs。

壓縮率、內(nèi)存占用測試

使用enwik9和silesia.tar兩個數(shù)據(jù)集測試幾個文件系統(tǒng)的壓縮率。測試結(jié)果如圖所示?？梢钥闯觯珽ROFS壓縮率和squashfs-16K接近，低于squashfs-128K，壓縮率接近0.5，可以節(jié)省接近一半的空間。

內(nèi)存壓縮測試方式為：開機、掛載文件系統(tǒng)，讀取整個測試文件，查看內(nèi)存占用情況。測試結(jié)果如下圖所示。可以看出，EROFS的內(nèi)存占用僅略高于非壓縮文件系統(tǒng)的ext4，遠低于squashfs。

實際環(huán)境測試

將安卓系統(tǒng)的/system；/vendor；/odm分區(qū)使用erofs，分別節(jié)省了30%-35%的空間，開機時間縮短2.3%。測試打開相機應(yīng)用花費時間，92次測試累計分布如圖所示?？梢钥闯觯珽ROFS的應(yīng)用開啟時間和ext4基本相同，甚至略優(yōu)于ext4。

總結(jié)

EROFS作為一個為資源有限的移動設(shè)備設(shè)計的只讀壓縮文件系統(tǒng)，在保證較高壓縮率的同時提供了高性能讀取、低內(nèi)存占用。在測試中，開啟時間甚至略快于ext4。目前EROFS已并入linux主線內(nèi)核，并且大規(guī)模部署在智能手機上。

審核編輯：湯梓紅