RTOS文件系統(tǒng)對(duì)比：LittleFS Vs. SPIFFS

在RTOS上免費(fèi)的文件系統(tǒng)本身就不多，廣泛使用且掉電安全的就更少了。本文選取當(dāng)前RTOS上比較受歡迎的兩個(gè)文件系統(tǒng) SPIFFS 和 LittleFS 做全方位的對(duì)比，以便項(xiàng)目上評(píng)估在RTOS上使用什么FS。

對(duì)嵌入式設(shè)備來(lái)說(shuō)，掉電時(shí)有發(fā)生。如果文件系統(tǒng)無(wú)法保證掉電安全，那么非常有可能在某一次掉電時(shí)，設(shè)備就變磚了。

不管是 SPIFFS 還是 LittleFS 的小型文件系統(tǒng)，都號(hào)稱做到掉電安全。而常見(jiàn)的FAT32由于無(wú)法做到掉電安全，或者某些特供版要付費(fèi)使用，更多時(shí)候是在需要Windows兼容性時(shí)才會(huì)考慮。

LittleFS 官網(wǎng)鏈接
SPIFFS 官網(wǎng)鏈接

不管是 SPIFFS 還是 LittleFS 都開(kāi)源在 GitHub 中。前者是 MIT開(kāi)源協(xié)議，后者是 BSD開(kāi)源協(xié)議。

在文章《了解常見(jiàn)的開(kāi)源協(xié)議(BSD, GPL, LGPL,MIT)》 上這么評(píng)論 BSD開(kāi)源協(xié)議

CopyBSD代碼鼓勵(lì)代碼共享，但需要尊重代碼作者的著作權(quán)。BSD由于允許使用者修改和重新發(fā)布代碼，也允許使用或在BSD代碼上開(kāi)發(fā)商業(yè)軟件發(fā)布和銷售，因此是對(duì)商業(yè)集成很友好的協(xié)議。

對(duì)MIT開(kāi)源協(xié)議有如下總結(jié)：

CopyMIT是和BSD一樣寬范的許可協(xié)議，作者只想保留版權(quán)，而無(wú)任何其他了限制。也就是說(shuō)，你必須在你的發(fā)行版里包含原許可協(xié)議的聲明，無(wú)論你是以二進(jìn)制發(fā)布的還是以源代碼發(fā)布的。

雖然從使用者的權(quán)限來(lái)說(shuō)，MIT開(kāi)源協(xié)議要比BSD開(kāi)源協(xié)議更少限制，但對(duì)企業(yè)商用來(lái)說(shuō)，兩者都可放心使用。

以GibHub上第一個(gè)提交作為項(xiàng)目開(kāi)始時(shí)間，那么SPIFFS項(xiàng)目作者是Peter Andersson，始于2013年7月4日。而LittleFS的作者是Christopher Haster，始于2017年2月20日。值得一提的是，LittleFS是ARM工程師折騰出來(lái)的文件系統(tǒng)，最先應(yīng)該是運(yùn)用在ARMmbed上的。

從時(shí)間上來(lái)說(shuō)，LittleFS項(xiàng)目要晚于SPIFFS項(xiàng)目。我們?cè)倏纯瓷鐓^(qū)當(dāng)前維護(hù)情況。

SPIFFS項(xiàng)目在2018年沒(méi)有任何提交，在2019年只有2個(gè)提交。分析提交補(bǔ)丁的內(nèi)容，我們發(fā)現(xiàn)對(duì)FS的運(yùn)行流程有實(shí)質(zhì)修改的最后一個(gè)提交是在2017年10月15日。換句話說(shuō)，SPIFFS項(xiàng)目要不是已經(jīng)足夠穩(wěn)定到?jīng)]有任何bug，要不漸漸被遺棄。

相比與SPIFFS項(xiàng)目的落日余暉，LittleFS更像冉冉升起的太陽(yáng)。從2017年到文本撰稿時(shí)的2020年3月初，社區(qū)一直非常活躍，以2019年為例，共計(jì)合并了124個(gè)提交，釋放了10個(gè)版本。目前最新的版本是2.1.4，而據(jù)我與作者的溝通，其正在為2.2版本做Bug修復(fù)。

到目前為止，在GitHub的統(tǒng)計(jì)上，SPIFFS項(xiàng)目共計(jì)934個(gè)星，而LittleFS項(xiàng)目達(dá)到1.7K個(gè)星。

因此，SPIFFS在社區(qū)上已經(jīng)不怎么維護(hù)，而LittleFS依然活躍。持續(xù)迭代的軟件會(huì)更強(qiáng)大和更穩(wěn)定。

對(duì)比靜態(tài)系統(tǒng)資源，我們主要比較編譯后的bin文件的text/data/bss段的大小。

Copytext段：存放代碼執(zhí)行語(yǔ)句data段：存放已初始化的全局變量和局部靜態(tài)變量bss段：未初始化的全局變量和局部靜態(tài)變量

這3個(gè)段的數(shù)據(jù)都是在編譯時(shí)就已經(jīng)確定下來(lái)的。如果某一個(gè)軟件代碼量非常龐大，其對(duì)應(yīng)的text段也會(huì)龐大，也就意味著在運(yùn)行時(shí)，需要用更多的內(nèi)存存放代碼語(yǔ)句。

我設(shè)計(jì)了下面的Shell命令統(tǒng)計(jì)靜態(tài)信息：

Copyfind -name "*.o" -exec size {} \; | awk '
	BEGIN{
		datasum = 0;
		textsum = 0;
		bsssum = 0;
	};
	/data/{
		getline;
		textsum += $1;
		datasum += $2;
		bsssum += $3;
	};
	END{
		printf "text %d\ndata %d\nbss %d\n", textsum, datasum, bsssum
	}
'

統(tǒng)計(jì)結(jié)果如下：

可以發(fā)現(xiàn)，SPIFFS的代碼量比LittleFS多53%，也就意味著SPIFFS需要更多的內(nèi)存存放代碼。

并不是所有的對(duì)比都可以直接從代碼上看出來(lái)，我們需要上機(jī)實(shí)測(cè)。實(shí)測(cè)是為了獲取最真實(shí)的對(duì)比數(shù)據(jù)。

不講環(huán)境和配置，直接對(duì)比SPIFFS和LittleFS，簡(jiǎn)直是在耍流氓。因此，我們先看看實(shí)測(cè)的環(huán)境。

測(cè)試時(shí)使用 0.3.7 版本的SPIFFS，其配置如下：

Copyphys_size = 5013504Bphys_addr = 0phys_erase_block = 32Klog_block_szie = 64Klog_page_size = 256B

測(cè)試時(shí)使用 2.1.3 版本的LittleFS，其配置如下：

Copyread_size = 256Bprog_size = 256Bblock_szie = 32K or 4Kcache_size = 256Blookahead_size = 16

在旺宏16M的SPI Nor上測(cè)試，SPI Nor運(yùn)行在4線讀寫命令和100MHz的SPI時(shí)鐘頻率上。用于做測(cè)試的分區(qū)有4896KB。

確保RTOS上并無(wú)任何無(wú)關(guān)進(jìn)程在搶CPU、IO資源。

換句話說(shuō)，測(cè)試在使用相同的硬件環(huán)境，無(wú)其他進(jìn)程干擾的情況下進(jìn)行。

文件系統(tǒng)需要額外空間存放一些元數(shù)據(jù)，因此用戶可用的空間實(shí)際大小并不直接等于分區(qū)大小。在 4896KB 的分區(qū)上分別掛載SPIFFS和Littlefs兩個(gè)文件系統(tǒng)，他們的可用空間是多少呢？

空的文件系統(tǒng)體現(xiàn)不出來(lái)，我們?cè)囍煌募到y(tǒng)中存放一些資源文件，再觀察使用情況。

這些資源文件在ubuntu的ext4 (塊大小為4K）中統(tǒng)計(jì)有2794KB的大小。以此為標(biāo)準(zhǔn)，我們看看SPIFFS和LittleFS的空間使用情況

由于LittleFS的塊大小決定了文件存儲(chǔ)的最小單位，因此分別統(tǒng)計(jì)塊大小為4K和32K的空間使用情況。當(dāng)塊越大，則越有可能會(huì)出現(xiàn)空間浪費(fèi)的情況。例如32K的塊大小，即使文件內(nèi)容只有1KB，LittleFS也會(huì)為其分配32K的空間，造成了31K的空間浪費(fèi)。

從空間利用率來(lái)看，SPIFFS略優(yōu)于LittleFS。

文件系統(tǒng)的掉電安全指在任意一時(shí)刻掉電，文件系統(tǒng)依然能保證其一致性，文件系統(tǒng)允許丟失掉電時(shí)沒(méi)寫完整的數(shù)據(jù)，但不能奔潰。

我們通過(guò)讀寫掉電的方式驗(yàn)證掉電安全，即在讀寫壓測(cè)時(shí)隨機(jī)時(shí)間掉電，再次上電后需要保證文件系統(tǒng)正常運(yùn)行且已寫入的文件數(shù)據(jù)不丟失。

SPIFFS掉電后需要調(diào)用SPIFFS_check()進(jìn)行修復(fù)，否則無(wú)法保證文件系統(tǒng)一致性。這就類似于ext4與e2fsck的關(guān)系。

在實(shí)測(cè)中，4896KB的空間，SPIFFS的修復(fù)竟然要5_{10s，相對(duì)于一次RTOS啟動(dòng)總耗時(shí)2}3s而言，簡(jiǎn)直無(wú)法忍受。在項(xiàng)目中已經(jīng)放棄對(duì)其的掉電壓測(cè)。

與SPIFFS相反，LittleFS在設(shè)計(jì)時(shí)就保證了掉電安全的問(wèn)題，因此不需要每次掉電后執(zhí)行修復(fù)工作。

而2.1.3版本的LittleFS在10W次的掉電測(cè)試中，在數(shù)萬(wàn)次掉電后小概率出現(xiàn)文件系統(tǒng)奔潰導(dǎo)致不能正確掛載的情況。分析良久，確認(rèn)是LittleFS本身邏輯的問(wèn)題。已反饋社區(qū)，預(yù)計(jì)在2.2版本解決。

總的來(lái)說(shuō)，SPIFFS的掉電安全修復(fù)耗時(shí)不符合項(xiàng)目需求，而LittleFS目前還做不到絕對(duì)的掉電安全。比較幸運(yùn)的是，LittleFS的掉電安全問(wèn)題復(fù)現(xiàn)概率比較低，且LittleFS社區(qū)比較活躍，在發(fā)現(xiàn)問(wèn)題后能及時(shí)提出解決方案。

當(dāng)空間使用率不同，測(cè)試的性能有可能不一樣，在SPIFFS中尤其明顯。

在讀寫性能表現(xiàn)上，SPIFFS最差，且剩余空間越少，SPIFFS寫性能越差。LittleFS的性能相對(duì)比較高和穩(wěn)定，塊大小會(huì)直接影響到寫性能。

動(dòng)態(tài)內(nèi)存指通過(guò)malloc申請(qǐng)分配的堆內(nèi)存大小。不管是SPIFFS還是LittleFS都是為小系統(tǒng)設(shè)計(jì)的，其內(nèi)存使用情況都經(jīng)過(guò)精心設(shè)計(jì)，內(nèi)存占用非常小。

LittleFS會(huì)為每個(gè)打開(kāi)的文件單獨(dú)申請(qǐng)一個(gè)cache_size的內(nèi)存，在測(cè)試時(shí)，cache_size 為256B。為了對(duì)比的公平性，我們假設(shè)SPIFFS和LittleFS打開(kāi)相同數(shù)量的文件情況下統(tǒng)計(jì)內(nèi)存。

兩者使用動(dòng)態(tài)內(nèi)存的情況相近，在最大打開(kāi)數(shù)量的情況下，SPIFFS使用動(dòng)態(tài)內(nèi)存略少。

由于SPIFFS的內(nèi)存使用并不會(huì)隨著打開(kāi)文件增加而增加，也就意味著，在打開(kāi)少量文件的情況下，LittleFS會(huì)比SPIFFS更少的動(dòng)態(tài)內(nèi)存使用量。

在讀寫壓測(cè)時(shí)，統(tǒng)計(jì)進(jìn)程使用的CPU資源百分比

可以發(fā)現(xiàn)，在相同情況下，LittleFS的CPU占用率會(huì)比SPIFFS少。

本文從多個(gè)方面對(duì)比評(píng)估 LittleFS 和 SPIFFS，發(fā)現(xiàn)資源、性能、掉電安全和社區(qū)支持情況來(lái)說(shuō)，后來(lái)者 LittleFS 已經(jīng)青出于藍(lán)。