在RTOS上免費的文件系統本身就不多，廣泛使用且掉電安全的就更少了。本文選取當前RTOS上比較受歡迎的兩個文件系統 SPIFFS 和 LittleFS 做全方位的對比，以便項目上評估在RTOS上使用什么FS。

對嵌入式設備來說，掉電時有發生。如果文件系統無法保證掉電安全，那么非常有可能在某一次掉電時，設備就變磚了。

不管是 SPIFFS 還是 LittleFS 的小型文件系統，都號稱做到掉電安全。而常見的FAT32由于無法做到掉電安全，或者某些特供版要付費使用，更多時候是在需要Windows兼容性時才會考慮。

LittleFS 官網鏈接
SPIFFS 官網鏈接

不管是 SPIFFS 還是 LittleFS 都開源在 GitHub 中。前者是 MIT開源協議，后者是 BSD開源協議。

在文章《了解常見的開源協議(BSD, GPL, LGPL,MIT)》 上這么評論 BSD開源協議

CopyBSD代碼鼓勵代碼共享，但需要尊重代碼作者的著作權。BSD由于允許使用者修改和重新發布代碼，也允許使用或在BSD代碼上開發商業軟件發布和銷售，因此是對商業集成很友好的協議。

對MIT開源協議有如下總結：

CopyMIT是和BSD一樣寬范的許可協議，作者只想保留版權，而無任何其他了限制。也就是說，你必須在你的發行版里包含原許可協議的聲明，無論你是以二進制發布的還是以源代碼發布的。

雖然從使用者的權限來說，MIT開源協議要比BSD開源協議更少限制，但對企業商用來說，兩者都可放心使用。

以GibHub上第一個提交作為項目開始時間，那么SPIFFS項目作者是Peter Andersson，始于2013年7月4日。而LittleFS的作者是Christopher Haster，始于2017年2月20日。值得一提的是，LittleFS是ARM工程師折騰出來的文件系統，最先應該是運用在ARMmbed上的。

從時間上來說，LittleFS項目要晚于SPIFFS項目。我們再看看社區當前維護情況。

SPIFFS項目在2018年沒有任何提交，在2019年只有2個提交。分析提交補丁的內容，我們發現對FS的運行流程有實質修改的最后一個提交是在2017年10月15日。換句話說，SPIFFS項目要不是已經足夠穩定到沒有任何bug，要不漸漸被遺棄。

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

到目前為止，在GitHub的統計上，SPIFFS項目共計934個星，而LittleFS項目達到1.7K個星。

因此，SPIFFS在社區上已經不怎么維護，而LittleFS依然活躍。持續迭代的軟件會更強大和更穩定。

對比靜態系統資源，我們主要比較編譯后的bin文件的text/data/bss段的大小。

Copytext段：存放代碼執行語句data段：存放已初始化的全局變量和局部靜態變量bss段：未初始化的全局變量和局部靜態變量

這3個段的數據都是在編譯時就已經確定下來的。如果某一個軟件代碼量非常龐大，其對應的text段也會龐大，也就意味著在運行時，需要用更多的內存存放代碼語句。

我設計了下面的Shell命令統計靜態信息：

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
	}
'

統計結果如下：

可以發現，SPIFFS的代碼量比LittleFS多53%，也就意味著SPIFFS需要更多的內存存放代碼。

并不是所有的對比都可以直接從代碼上看出來，我們需要上機實測。實測是為了獲取最真實的對比數據。

不講環境和配置，直接對比SPIFFS和LittleFS，簡直是在耍流氓。因此，我們先看看實測的環境。

測試時使用 0.3.7 版本的SPIFFS，其配置如下：

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

測試時使用 2.1.3 版本的LittleFS，其配置如下：

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

在旺宏16M的SPI Nor上測試，SPI Nor運行在4線讀寫命令和100MHz的SPI時鐘頻率上。用于做測試的分區有4896KB。

確保RTOS上并無任何無關進程在搶CPU、IO資源。

換句話說，測試在使用相同的硬件環境，無其他進程干擾的情況下進行。

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

空的文件系統體現不出來，我們試著往不同文件系統中存放一些資源文件，再觀察使用情況。

這些資源文件在ubuntu的ext4 (塊大小為4K）中統計有2794KB的大小。以此為標準，我們看看SPIFFS和LittleFS的空間使用情況

由于LittleFS的塊大小決定了文件存儲的最小單位，因此分別統計塊大小為4K和32K的空間使用情況。當塊越大，則越有可能會出現空間浪費的情況。例如32K的塊大小，即使文件內容只有1KB，LittleFS也會為其分配32K的空間，造成了31K的空間浪費。

從空間利用率來看，SPIFFS略優于LittleFS。

文件系統的掉電安全指在任意一時刻掉電，文件系統依然能保證其一致性，文件系統允許丟失掉電時沒寫完整的數據，但不能奔潰。

我們通過讀寫掉電的方式驗證掉電安全，即在讀寫壓測時隨機時間掉電，再次上電后需要保證文件系統正常運行且已寫入的文件數據不丟失。

SPIFFS掉電后需要調用SPIFFS_check()進行修復，否則無法保證文件系統一致性。這就類似于ext4與e2fsck的關系。

在實測中，4896KB的空間，SPIFFS的修復竟然要5_{10s，相對于一次RTOS啟動總耗時2}3s而言，簡直無法忍受。在項目中已經放棄對其的掉電壓測。

與SPIFFS相反，LittleFS在設計時就保證了掉電安全的問題，因此不需要每次掉電后執行修復工作。

而2.1.3版本的LittleFS在10W次的掉電測試中，在數萬次掉電后小概率出現文件系統奔潰導致不能正確掛載的情況。分析良久，確認是LittleFS本身邏輯的問題。已反饋社區，預計在2.2版本解決。

總的來說，SPIFFS的掉電安全修復耗時不符合項目需求，而LittleFS目前還做不到絕對的掉電安全。比較幸運的是，LittleFS的掉電安全問題復現概率比較低，且LittleFS社區比較活躍，在發現問題后能及時提出解決方案。

當空間使用率不同，測試的性能有可能不一樣，在SPIFFS中尤其明顯。

在讀寫性能表現上，SPIFFS最差，且剩余空間越少，SPIFFS寫性能越差。LittleFS的性能相對比較高和穩定，塊大小會直接影響到寫性能。

動態內存指通過malloc申請分配的堆內存大小。不管是SPIFFS還是LittleFS都是為小系統設計的，其內存使用情況都經過精心設計，內存占用非常小。

LittleFS會為每個打開的文件單獨申請一個cache_size的內存，在測試時，cache_size 為256B。為了對比的公平性，我們假設SPIFFS和LittleFS打開相同數量的文件情況下統計內存。

兩者使用動態內存的情況相近，在最大打開數量的情況下，SPIFFS使用動態內存略少。

由于SPIFFS的內存使用并不會隨著打開文件增加而增加，也就意味著，在打開少量文件的情況下，LittleFS會比SPIFFS更少的動態內存使用量。

在讀寫壓測時，統計進程使用的CPU資源百分比

可以發現，在相同情況下，LittleFS的CPU占用率會比SPIFFS少。

本文從多個方面對比評估 LittleFS 和 SPIFFS，發現資源、性能、掉電安全和社區支持情況來說，后來者 LittleFS 已經青出于藍。