引言

隨著科技的發(fā)展和網(wǎng)絡(luò)技術(shù)的進(jìn)步，計(jì)算機(jī)存儲(chǔ)空間愈加緊張，存儲(chǔ)空間對(duì)文件系統(tǒng)的功能需求越來(lái)越大，大規(guī)模的數(shù)據(jù)增長(zhǎng)為文件存儲(chǔ)、非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)提出了新的挑戰(zhàn)。

對(duì)于許多物聯(lián)網(wǎng)設(shè)備而言，擁有一個(gè)小型且具有彈性的文件系統(tǒng)至關(guān)重要，littlefs文件系統(tǒng)應(yīng)運(yùn)而生。littlefs文件系統(tǒng)在2017年由Christopher Haster開發(fā)，遵循Apache 2.0協(xié)議，被應(yīng)用在ARM的IoT設(shè)備Mbed操作系統(tǒng)。littlefs文件系統(tǒng)能夠讓嵌入式系統(tǒng)在ROM和RAM資源有限的情況下，還具備文件系統(tǒng)基本的掉電恢復(fù)、磨損均衡的功能。

littlefs是一種極簡(jiǎn)的嵌入式文件系統(tǒng)，適配于norflash，它所采用的文件系統(tǒng)結(jié)構(gòu)與運(yùn)行機(jī)制，使得文件系統(tǒng)的存儲(chǔ)結(jié)構(gòu)更加緊湊，運(yùn)行中對(duì)RAM的消耗更小。它的設(shè)計(jì)策略采用了與傳統(tǒng)“使用空間換時(shí)間”完全相反的“使用時(shí)間換空間”的策略，雖然它極大地壓縮了文件系統(tǒng)存儲(chǔ)空間，但是運(yùn)行時(shí)也增加了RAM的消耗，不可避免地帶來(lái)了隨機(jī)讀寫時(shí)IO性能的降低。

目前，OpenAtom OpenHarmony（以下簡(jiǎn)稱“OpenHarmony”） liteos_m內(nèi)核采用了littlefs作為默認(rèn)的文件系統(tǒng)。本文著重介紹了littlefs文件系統(tǒng)的存儲(chǔ)結(jié)構(gòu)，并根據(jù)對(duì)讀寫過(guò)程的分析，解析引起littlefs文件系統(tǒng)隨機(jī)讀寫IO性能瓶頸的根本原因，然后提出一些提升littlefs隨機(jī)讀寫IO性能優(yōu)化策略。

littlefs文件系統(tǒng)結(jié)構(gòu)

文件系統(tǒng)存儲(chǔ)結(jié)構(gòu)信息基本以SuperBlock為開端，然后尋找到文件系統(tǒng)根節(jié)點(diǎn)，再根據(jù)根節(jié)點(diǎn)，逐步拓展成一個(gè)文件系統(tǒng)樹形結(jié)構(gòu)體。littlefs也與此類似，以SuperBlock和根目錄為起點(diǎn)，構(gòu)建了一個(gè)樹形存儲(chǔ)結(jié)構(gòu)。不同的是littlefs的根（"/"）直接附加在SuperBlock之后，與其共享元數(shù)據(jù)對(duì)（metadata pair）。littlefs中目錄或者文件都是以該根節(jié)點(diǎn)為起點(diǎn)，構(gòu)建了與其他文件系統(tǒng)類似的樹形結(jié)構(gòu)。

littlefs文件系統(tǒng)樹形存儲(chǔ)結(jié)構(gòu)如下：

圖1 littlefs文件系統(tǒng)樹形存儲(chǔ)結(jié)構(gòu)示意圖

如圖1所示，存儲(chǔ)littlefs文件系統(tǒng)元數(shù)據(jù)的結(jié)構(gòu)為元數(shù)據(jù)對(duì)，即兩個(gè)相互輪轉(zhuǎn)、互為表里的Block。存儲(chǔ)SuperBlock的元數(shù)據(jù)對(duì)固定存儲(chǔ)在block 0和block 1，并且文件系統(tǒng)根目錄附加在SuperBlock的尾部，與SuperBlock共享元數(shù)據(jù)對(duì)。元數(shù)據(jù)的存儲(chǔ)是以tag的格式存儲(chǔ)在元數(shù)據(jù)對(duì)內(nèi)，按照元數(shù)據(jù)的類型，將Tag分為標(biāo)準(zhǔn)文件、目錄、用戶數(shù)據(jù)、元數(shù)據(jù)對(duì)尾部指針等類型。littlefs借助于這些不同類型tag信息，將littlefs文件系統(tǒng)組織成結(jié)構(gòu)緊湊的樹形存儲(chǔ)結(jié)構(gòu)體。例如tail類型的tag可以將比較大的目錄結(jié)構(gòu)使用多個(gè)元數(shù)據(jù)對(duì)存儲(chǔ)，并且使用tail類型的tag將這些元數(shù)據(jù)對(duì)連接成一個(gè)單向的鏈表。而目錄類型的tag則直接指向該目錄的元數(shù)據(jù)對(duì)，例如"tag: dir_data"類型的tag指向目錄"/data"的元數(shù)據(jù)對(duì)，而該元數(shù)據(jù)對(duì)中又可以包含子目錄或者文件（Inline類型或者outline類型）。 ?

littlefs目錄存儲(chǔ)結(jié)構(gòu)

littlefs目錄的引用為其父目錄元數(shù)據(jù)對(duì)（metadata pair）內(nèi)的一個(gè)dir類型的Tag，而其內(nèi)容則占用一個(gè)或者多個(gè)元數(shù)據(jù)對(duì)。一個(gè)目錄的元數(shù)據(jù)對(duì)內(nèi)既可以包含子目錄引用的Tag，也可以包含屬于該目錄下文件的Inline類型的Tag或者指向該文件的CTZ跳表的CTZ類型Tag指針。最終littlefs通過(guò)一層層目錄或者文件的索引，組成了文件系統(tǒng)的樹形存儲(chǔ)結(jié)構(gòu)。 ?

littlefs文件存儲(chǔ)方式

littlefs文件系統(tǒng)為極簡(jiǎn)的文件系統(tǒng)，使用最小的存儲(chǔ)開銷，同時(shí)實(shí)現(xiàn)對(duì)小文件（Bytes級(jí)別）和大文件（MB級(jí)別）的支持，對(duì)小于一個(gè)Block八分之一長(zhǎng)度的文件，采用Inline類型的方式存儲(chǔ)，而大于或者等于Block八分之一長(zhǎng)度的文件則采用Outline的方式存儲(chǔ)（CTZ Skip-list）。

1.2.1 inline文件存儲(chǔ)方式

Inline文件存儲(chǔ)方式，如圖2所示，即將文件內(nèi)容與文件名稱一同存儲(chǔ)在其父目錄的元數(shù)據(jù)對(duì)（metadata pair）內(nèi)，一個(gè)Tag表示其名稱，一個(gè)Tag表示其內(nèi)容。

圖2 littlefs Inline文件存儲(chǔ)結(jié)構(gòu)

?1.2.2 outline文件存儲(chǔ)方式

Outline文件存儲(chǔ)方式，如圖3所示，文件其父目錄的元數(shù)據(jù)對(duì)（metadata pair）內(nèi)，一個(gè)Tag表示文件名稱，另一個(gè)Tag為CTZ類型，其指向存儲(chǔ)文件內(nèi)容的鏈表頭。

圖3 littlefs Outline文件存儲(chǔ)結(jié)構(gòu)

CTZ跳表（CTZ skip-list）鏈表的特別之處是：

（1）CTZ跳表的頭部指向鏈表的結(jié)尾；

（2）CTZ跳表內(nèi)Block內(nèi)包含一個(gè)以上的跳轉(zhuǎn)指針。

若是使用常規(guī)鏈表，存儲(chǔ)文件前一個(gè)數(shù)據(jù)塊包含指向后一個(gè)數(shù)據(jù)塊指針，那么在文件追加或者修改內(nèi)容的時(shí)候，則需要存儲(chǔ)文件起始?jí)K到目標(biāo)塊的所有內(nèi)容拷貝到新塊內(nèi)，并且更新對(duì)后一個(gè)數(shù)據(jù)塊的指針。而若是采用反向鏈表的方式，則在文件追加或者修改內(nèi)容的時(shí)候，則只需要將存儲(chǔ)文件目標(biāo)塊到鏈表結(jié)尾的塊的所有內(nèi)容拷貝到新塊內(nèi)，然后更新對(duì)后一個(gè)數(shù)據(jù)塊內(nèi)對(duì)前一個(gè)數(shù)據(jù)塊指向的指針，這樣對(duì)于文件追加模式可以減少修改量。另外，為了加快索引，采用了跳表的方式，Block內(nèi)包含一個(gè)以上的跳轉(zhuǎn)指針，規(guī)則為：若一個(gè)數(shù)據(jù)塊在CTZ skip-list鏈表內(nèi)的索引值N能被 2^X整除的數(shù)，那么他就存在指向N – 2^X的指針，指針的數(shù)目為ctz(N)+1。如表1，對(duì)于block 2,包含了2個(gè)指針，分別指向block 0和block 1，其它塊也是采用相同的規(guī)則。

表1 littlefs 塊的skip-list鏈表計(jì)算樣表

littlefs文件讀寫流程

以上章節(jié)針對(duì)littlefs文件系統(tǒng)結(jié)構(gòu)進(jìn)行了分析，接下來(lái)開始探討littlefs內(nèi)部的運(yùn)行機(jī)制，以讀寫流程為例，分析littlefs隨機(jī)讀寫的IO性能瓶頸。

需要提前了解的是，littlefs的文件只擁有一個(gè)緩存，寫時(shí)作為寫緩存使用，讀時(shí)作為讀緩存使用。

littlefs文件讀過(guò)程

以下圖4是littlefs讀文件的流程圖，在讀流程的開始先檢測(cè)先前是否有對(duì)文件的寫操作，即檢測(cè)文件緩存是否作為寫緩存。若是，則強(qiáng)制將緩存中的數(shù)據(jù)刷新到存儲(chǔ)器，根據(jù)文件類型和訪問(wèn)位置，或者直接從文件所在的元數(shù)據(jù)對(duì)讀取，或者從存儲(chǔ)文件內(nèi)容的CTZ跳表內(nèi)的塊內(nèi)讀取，再將數(shù)據(jù)拷貝到用戶緩存沖，并從存儲(chǔ)器預(yù)讀取數(shù)據(jù)將文件緩沖區(qū)填滿。具體過(guò)程如下： ?

圖4 littlefs文件系統(tǒng)讀過(guò)程流程圖 ?

littlefs文件寫過(guò)程

以下圖5是littlefs寫文件的流程圖，在寫流程的開始先檢測(cè)先前是否有對(duì)文件的讀操作，即檢測(cè)文件緩存是否作為讀緩存。若是，則清除緩存中的數(shù)據(jù)。若是APPEND類型的寫操作，則直接減寫位置定位到文件末尾。若寫位置超過(guò)文件長(zhǎng)度，說(shuō)明文件結(jié)尾與寫位置間存在空洞，則使用0填充文件中的空洞。對(duì)應(yīng)Inline類型文件，若推測(cè)到寫后，文件長(zhǎng)度超過(guò)了閾值，則將文件轉(zhuǎn)成Outline類型。對(duì)于Outline類型的文件，若是修改文件的內(nèi)容，則需要申請(qǐng)新塊，并將目標(biāo)塊內(nèi)訪問(wèn)位置之前的所有內(nèi)容都拷貝到新塊，將buffer中的用戶數(shù)據(jù)寫到緩沖區(qū)或者刷新到存儲(chǔ)器。

注意：寫后并沒(méi)有立刻更新Inline文件的commit，或者更新Outline文件的CTZ跳表，這些操作被延遲在文件關(guān)閉或者緩沖區(qū)再次作為讀緩存的時(shí)候強(qiáng)制文件刷新時(shí)更新。

圖5 littlefs文件系統(tǒng)寫過(guò)程流程圖

littlefs文件隨機(jī)讀寫IO性能瓶頸分析

littlefs文件只有一個(gè)緩沖區(qū)，為讀寫復(fù)用。根據(jù)littlefs運(yùn)行機(jī)制，若是對(duì)文件先讀后寫，那么僅需要直接將緩沖區(qū)的數(shù)據(jù)清空，然后申請(qǐng)一個(gè)新塊將目標(biāo)塊內(nèi)訪問(wèn)位置直接的數(shù)據(jù)拷貝到新塊中，然后寫數(shù)據(jù)到新塊。若是先寫后讀，那么需要將數(shù)據(jù)刷新到存儲(chǔ)器，同時(shí)更新文件的CTZ跳表。在這個(gè)過(guò)程中，不僅涉及到刷新數(shù)據(jù)到存儲(chǔ)器，而且涉及到分配新塊替換目標(biāo)塊之后的所有塊從而更新CTZ跳表，出現(xiàn)多次費(fèi)時(shí)的擦除塊動(dòng)作。在隨機(jī)讀寫的過(guò)程中，頻繁發(fā)生讀寫切換，也就頻繁地發(fā)生申請(qǐng)新塊、擦除新塊（非常費(fèi)時(shí)）、數(shù)據(jù)搬移等等動(dòng)作，嚴(yán)重地影響了IO性能。 ?

littlefs讀寫IO性能優(yōu)化策略

由“2.3 littlefs文件隨機(jī)讀寫IO性能瓶頸分析”章節(jié)描述可知，影響littlefs文件隨機(jī)讀寫IO性能的主要原因是文件只有一個(gè)的緩存且被讀寫復(fù)用，造成在讀寫切換的過(guò)程中頻繁地發(fā)生文件刷新，申請(qǐng)新塊，然后執(zhí)行費(fèi)時(shí)的塊擦除，再將CTZ跳表上塊內(nèi)的block內(nèi)容搬移到新塊，進(jìn)而更新CTZ跳表，這嚴(yán)重影響了隨機(jī)讀寫IO的性能。

所以，在RAM空間允許的情況下，可以考慮“使用空間換時(shí)間”的策略，適當(dāng)?shù)卦黾游募彺娴臄?shù)量，使一個(gè)文件擁有多個(gè)緩沖區(qū)，而這些緩沖區(qū)對(duì)應(yīng)著一個(gè)Block的大小，在一定的條件下一次刷新一個(gè)Block，從而避免過(guò)多的數(shù)據(jù)搬移。另外，littlefs的策略是“使用時(shí)間換空間”，但是每個(gè)文件都擁有一個(gè)緩沖區(qū)明顯浪費(fèi)空間。因?yàn)樵谝欢螘r(shí)間內(nèi)，只會(huì)有一定數(shù)量的文件被執(zhí)行讀或者寫，所以可以考慮建立一個(gè)擁有一定數(shù)量的緩存池，使緩存在文件間共享。

圖6 littlefs優(yōu)化策略

優(yōu)化的策略如圖6所示，littlefs文件緩存池為一個(gè)雙向鏈表fc_pool，緩存池隨著被打開文件的個(gè)數(shù)的增長(zhǎng)而延長(zhǎng)，直到用戶設(shè)置的最大限制；緩存池隨著文件的關(guān)閉而逐漸縮減。

每個(gè)緩存掛載在fc_pool緩存池雙向鏈表上，當(dāng)緩存被寫或者被讀時(shí)，則將緩存移到鏈表開頭，那么緩存池鏈表末尾的緩存則為待老化的緩存，可以優(yōu)先被選擇回收。

在申請(qǐng)緩存時(shí)，優(yōu)先從緩沖池鏈表末尾選擇空閑緩存；若無(wú)空閑緩存，則考慮搶占讀緩存；若緩存池既沒(méi)有空閑緩存也沒(méi)有讀緩存，在緩存池長(zhǎng)度沒(méi)有達(dá)到優(yōu)化限制的情況下，則創(chuàng)建新緩存，然后將新緩沖添加到鏈表頭；若緩存池既沒(méi)有空閑緩存也沒(méi)有讀緩存，并且緩存池長(zhǎng)度已經(jīng)達(dá)到用戶限制，那么就需要從鏈表末尾搶占一個(gè)寫緩存，并強(qiáng)制占有該緩存的文件執(zhí)行刷新，進(jìn)而完成搶占。

在文件被關(guān)閉或者刷新時(shí)，主動(dòng)釋放緩存到緩存池，掛載在雙向鏈表的末尾。

使用上述策略對(duì)文件緩存進(jìn)行優(yōu)化，可以在一定程度上減少因更新文件內(nèi)容而執(zhí)行的存儲(chǔ)器塊擦除動(dòng)作，從而增加隨機(jī)讀寫的IO性能，也間接地延長(zhǎng)了NorFlash的壽命。

總結(jié)

通過(guò)本文的講解，相信大家對(duì)于littlefs文件系統(tǒng)有了較為全面的了解?？偟膩?lái)說(shuō)，littlefs是一種極簡(jiǎn)的文件系統(tǒng)，實(shí)現(xiàn)了文件系統(tǒng)基本的數(shù)據(jù)緩存、掉電恢復(fù)、磨損均衡等功能，在資源相對(duì)富裕的環(huán)境中，開發(fā)者們可以對(duì)其運(yùn)行機(jī)制甚至存儲(chǔ)結(jié)構(gòu)進(jìn)行“使用空間換時(shí)間”的優(yōu)化策略，提升讀寫的IO性能。

學(xué)會(huì)有效地利用文件系統(tǒng)往往能起到事半功倍的作用，希望開發(fā)者能夠?qū)⑺鶎W(xué)知識(shí)有效應(yīng)用到未來(lái)的開發(fā)工作中，從而提高開發(fā)工作的效率。

審核編輯：湯梓紅

?