RTOS文件系统对比:LittleFS Vs. SPIFFS

2019/04/10 10:10
阅读数 127

概述

在RTOS上免费的文件系统本身就不多,广泛使用且掉电安全的就更少了。本文选取当前RTOS上比较受欢迎的两个文件系统 SPIFFS 和 LittleFS 做全方位的对比,以便项目上评估在RTOS上使用什么FS。

对嵌入式设备来说,掉电时有发生。如果文件系统无法保证掉电安全,那么非常有可能在某一次掉电时,设备就变砖了。

不管是 SPIFFS 还是 LittleFS 的小型文件系统,都号称做到掉电安全。而常见的FAT32由于无法做到掉电安全,或者某些特供版要付费使用,更多时候是在需要Windows兼容性时才会考虑。

LittleFS 官网链接 SPIFFS 官网链接

开源协议

不管是 SPIFFS 还是 LittleFS 都开源在 GitHub 中。前者是 MIT开源协议,后者是 BSD开源协议。

在文章《了解常见的开源协议(BSD, GPL, LGPL,MIT)》 上这么评论 BSD开源协议

BSD代码鼓励代码共享,但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码,也允许使用或在BSD代码上开发商业软件发布和销售,因此是对商业集成很友好的协议。

对MIT开源协议有如下总结:

MIT是和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段的大小。

text段:存放代码执行语句
data段:存放已初始化的全局变量和局部静态变量
bss段:未初始化的全局变量和局部静态变量

这3个段的数据都是在编译时就已经确定下来的。如果某一个软件代码量非常庞大,其对应的text段也会庞大,也就意味着在运行时,需要用更多的内存存放代码语句。

我设计了下面的Shell命令统计静态信息:

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

统计结果如下:

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 已经青出于蓝。

原文出处:https://www.cnblogs.com/gmpy/p/12498999.html

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部