## 概述
在RTOS上免费的文件系统本身就不多，广泛使用且掉电安全的就更少了。本文选取当前RTOS上比较受欢迎的两个文件系统 SPIFFS 和 LittleFS 做全方位的对比，以便项目上评估在RTOS上使用什么FS。
对嵌入式设备来说，掉电时有发生。如果文件系统无法保证掉电安全，那么非常有可能在某一次掉电时，设备就变砖了。
不管是 SPIFFS 还是 LittleFS 的小型文件系统，都号称做到掉电安全。而常见的FAT32由于无法做到掉电安全，或者某些特供版要付费使用，更多时候是在需要Windows兼容性时才会考虑。
[LittleFS 官网链接](https://github.com/ARMmbed/littlefs)
[SPIFFS 官网链接](https://github.com/pellepl/spiffs)
## 开源协议
不管是 SPIFFS 还是 LittleFS 都开源在 GitHub 中。前者是 MIT开源协议，后者是 BSD开源协议。
在文章[《了解常见的开源协议(BSD, GPL, LGPL,MIT)》](https://www.cnblogs.com/sadkilo/p/5962371.html) 上这么评论 BSD开源协议
BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。
对MIT开源协议有如下总结：
MIT是和BSD一样宽范的许可协议，作者只想保留版权，而无任何其他了限制。也就是说，你必须在你的发行版里包含原许可协议的声明，无论你是以二进制发布的还是以源代码发布的。
虽然从使用者的权限来说，MIT开源协议要比BSD开源协议更少限制，但**对企业商用来说，两者都可放心使用**。
## 社区维护情况
以GibHub上第一个提交作为项目开始时间，那么SPIFFS项目作者是[Peter Andersson](https://github.com/pellepl)，始于2013年7月4日。而LittleFS的作者是[Christopher Haster](https://github.com/geky)，始于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文件的texthttps://img.qb5200.com/download-x/data/bss段的大小。
text段：存放代码执行语句
data段：存放已初始化的全局变量和局部静态变量
bss段：未初始化的全局变量和局部静态变量
这3个段的数据都是在编译时就已经确定下来的。如果某一个软件代码量非常庞大，其对应的text段也会庞大，也就意味着在运行时，需要用更多的内存存放代码语句。
我设计了下面的Shell命令统计静态信息：
```Bash
find -name "*.o" -exec size {} \; | awk '
BEGIN{
datasum = 0;
textsum = 0;
bsssum = 0;
};
https://img.qb5200.com/download-x/data/{
getline;
textsum += $1;
datasum += $2;
bsssum += $3;
};
END{
printf "text %d\ndata %d\nbss %d\n", textsum, datasum, bsssum
}
'
```
统计结果如下：
| FS | text | data | bss |
| :---: | :---: | :---: | :---: |
| littlefs | 24000 | 0 | 0 |
| spiffs | 36940 | 0 | 0 |
可以发现，SPIFFS的代码量比LittleFS多53%，也就意味着SPIFFS需要更多的内存存放代码。
## 实测-环境
并不是所有的对比都可以直接从代码上看出来，我们需要上机实测。实测是为了获取最真实的对比数据。
不讲环境和配置，直接对比SPIFFS和LittleFS，简直是在耍流氓。因此，我们先看看实测的环境。
测试时使用 *0.3.7* 版本的SPIFFS，其配置如下：
```
phys_size = 5013504B
phys_addr = 0
phys_erase_block = 32K
log_block_szie = 64K
log_page_size = 256B
```
测试时使用 *2.1.3* 版本的LittleFS，其配置如下：
```
read_size = 256B
prog_size = 256B
block_szie = 32K or 4K
cache_size = 256B
lookahead_size = 16
```
在旺宏16M的SPI Nor上测试，SPI Nor运行在4线读写命令和100MHz的SPI时钟频率上。用于做测试的分区有4896KB。
确保RTOS上并无任何无关进程在抢CPU、IO资源。
换句话说，测试在使用相同的硬件环境，无其他进程干扰的情况下进行。
## 空间利用率
文件系统需要额外空间存放一些元数据，因此用户可用的空间实际大小并不直接等于分区大小。在 4896KB 的分区上分别挂载SPIFFS和Littlefs两个文件系统，他们的可用空间是多少呢？
空的文件系统体现不出来，我们试着往不同文件系统中存放一些资源文件，再观察使用情况。
这些资源文件在ubuntu的ext4 (块大小为4K）中统计有2794KB的大小。以此为标准，我们看看SPIFFS和LittleFS的空间使用情况
| FS | used(KB) | total(KB) | note |
| :---: | :---: | :---: | :--- |
| SPIFFS | 2722 | 4607 | |
| LittleFS | 3680 | 4896 | block size = 32K |
| LittleFS | 2800 | 4896 | block size = 4K |
由于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中尤其明显。
| IO操作 | 空闲空间 | SPIFFS | LittleFS(32K Block) | LittleFS(4K Block) |
| :---: | :---: | :---: | :---: | :---: |
| 读 | 20% | 6095.24 KB/s | 8629.21 KB/s | 7529.41 KB/s |
| 读 | 100% | 6564.10 KB/s | 8727.27 KB/s | 7314.29 KB/s |
| 写 | 20% | 21.64 KB/s | 142.54 KB/s | 121.92 KB/s |
| 写 | 100% | 128.49 KB/s | 155.37 KB/s | 127.87 KB/s |
在读写性能表现上，SPIFFS最差，且剩余空间越少，SPIFFS写性能越差。LittleFS的性能相对比较高和稳定，块大小会直接影响到写性能。
## 动态内存
动态内存指通过```malloc```申请分配的堆内存大小。不管是SPIFFS还是LittleFS都是为小系统设计的，其内存使用情况都经过精心设计，内存占用非常小。
LittleFS会为每个打开的文件单独申请一个```cache_size```的内存，在测试时，cache_size 为256B。为了对比的公平性，我们假设SPIFFS和LittleFS打开相同数量的文件情况下统计内存。
| LittleFS | SPIFFS |
| :---: | :---: |
| 3856 B | 3790 B |
两者使用动态内存的情况相近，在最大打开数量的情况下，SPIFFS使用动态内存略少。
由于SPIFFS的内存使用并不会随着打开文件增加而增加，也就意味着，在打开少量文件的情况下，LittleFS会比SPIFFS更少的动态内存使用量。
## CPU占用
在读写压测时，统计进程使用的CPU资源百分比
| LittleFS (32K) | LittleFS (4K) | SPIFFS |
| :---: | :---: | :---: |
| 22~27 | 27~50 | 44~80 |
可以发现，在相同情况下，LittleFS的CPU占用率会比SPIFFS少。
## 总结
本文从多个方面对比评估 LittleFS 和 SPIFFS，发现资源、性能、掉电安全和社区支持情况来说，后来者 LittleFS 已经青出于蓝。
