引言

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

對于許多物聯(lián)網(wǎng)設(shè)備而言，擁有一個小型且具有彈性的文件系統(tǒng)至關(guān)重要，littlefs文件系統(tǒng)應(yīng)運而生。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是一種極簡的嵌入式文件系統(tǒng)，適配于norflash，它所采用的文件系統(tǒng)結(jié)構(gòu)與運行機(jī)制，使得文件系統(tǒng)的存儲結(jié)構(gòu)更加緊湊，運行中對RAM的消耗更小。它的設(shè)計策略采用了與傳統(tǒng)“使用空間換時間”完全相反的“使用時間換空間”的策略，雖然它極大地壓縮了文件系統(tǒng)存儲空間，但是運行時也增加了RAM的消耗，不可避免地帶來了隨機(jī)讀寫時IO性能的降低。

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

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

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

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

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

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

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

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

littlefs文件存儲方式

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

1.2.1 inline文件存儲方式

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

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

?1.2.2 outline文件存儲方式

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

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

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

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

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

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

表1 littlefs 塊的skip-list鏈表計算樣表

littlefs文件讀寫流程

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

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

littlefs文件讀過程

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

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

littlefs文件寫過程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

審核編輯：湯梓紅

?