嵌入式技术论坛
直播中

lalajie

8年用户 1231经验值
擅长:模拟技术 存储技术
私信 关注
[问答]

littlefs文件系统读写文件达到几K时会引起系统重启是何原因

最近在使用littlefs文件系统,由于要跟原系统做兼容
没有使用FAL接口及MTD设备,直接使用lfs操作的块设备,

从官方的资料来看,littlefs有点还是很明显的,
占用资源少,自带磨损均衡等等。。。

移植完成后,测试lfs系统挂载及读写操作都没有问题,
但执行效率极慢,连最基本的ls命令都是一个一个的出,
而同样的工程,换成FAT系统,就完全不一样,效果如下

使用littlefs时的效果

1.jpg

使用fat时的效果

1.jpg

文件使用的是同一个工程,底层SPI驱动都是完全一样的,
不知道为什么会差别这么大,

而且使用littlefs时,读写文件达到几K时,经常会引起系统重启,
具体原因未知,还在查找中

回帖(2)

陈丽

2022-10-8 14:32:14
建议用fal 转mtd,我用的好像速度没问题
举报

lalajie

2022-10-8 14:32:55
为了验证littlefs的读写测试策略,我尝试进行了如下测试,
并将测试过程中littlefs对SPI Flash的所有操作全部打印了出来,然后进行了分析。

测试用到的代码如下(其中addr初始化的值需要每次手动更改)

const char spi_test[] = "LittleFS - A high-integrity embedded file system ";
        char test[256];
        u32 i, cnt = 0;
        u32 addr1=8192;
        int fd;
        fd = open("LittleFS.bin", O_WRONLY | O_CREAT, 0);
        for(i=0;i<4;i++)
        {
rt_kprintf("SPI Flash write time #%d -- %dn",i , rt_tick_get());
                rt_snprintf(test, sizeof(test), "%s -- %d", spi_test, rt_tick_get());
                lseek(fd, addr1, SEEK_SET);
                write(fd, (u8 *)test, sizeof(test));
                addr1 += sizeof(test);
        }
        close(fd);
        addr1 = 0;
        fd = open("LittleFS.bin", O_RDONLY, 0);
        for(i=0;i<36;i++)
        {
                rt_kprintf("SPI Flash read time #%d -- %dn",i , rt_tick_get());
                lseek(fd, addr1, SEEK_SET);
                read(fd, (u8 *)test, sizeof(test));
                addr1 += sizeof(test);
        }
        close(fd);
具体的测试步骤如下:
第一次测试
新建文件LittleFS.bin,从文件0地址处开始,写入四次数据,每次256字节

前两次写入时,写入块地址 —— 0x75F000,写入数据重复 “LittleFS — 177”
第三次写入时,写入块地址 —— 0x760000,先复制0x75F000处的两次数据到0x760000,再写入第三次的数据 “LittleFS — 203”
第四次写入时,写入块地址 —— 0x761000,先复制0x760000处的两次数据到0x761000,再写入第四次的数据 “LittleFS — 228
写入结束,文件大小1024Byte,存储块在0x761000处
第二次测试
从文件LittleFS.bin 4096地址处开始,写入四次数据,每次256字节

第一次写入,写入块地址 —— 0x783000,先复制0x761000处的四次数据到0x783000,然后从0x783400处写入3072Byte,填充数据到0x783FFF,再从0x784000处开始,写入本次的数据,然而数据丢失,只写入“?”
第二次写入,写入块地址 —— 0x785000,先复制0x784000处的一次数据到0x785000,再写入第二次的数据 “LittleFS — 281”
第三次写入,写入块地址 —— 0x786000,先复制0x785000处的两次数据到0x785000,再写入第三次的数据 “LittleFS — 309”
第四次写入,写入块地址 —— 0x787000,先复制0x786000处的三次数据到0x785000,再写入第四次的数据 “LittleFS — 343”
写入结束,文件大小5120Byte,存储块在0x783000->0x787000处
第三次测试
从文件LittleFS.bin 5120地址处开始,写入四次数据,每次256字节

第一次写入,写入块地址 —— 0x6B7000,先复制0x787000处的四次数据到0x6B7000,再从0x6B7400处开始,写入本次的数据 “LittleFS — 190”
第二次写入,写入块地址 —— 0x6B8000,先复制0x6B7000处的五次数据到0x6B8000,再写入第二次的数据 “LittleFS — 248”
第三次写入,写入块地址 —— 0x6B9000,先复制0x6B8000处的六次数据到0x6B9000,再写入第三次的数据 “LittleFS — 304”
第四次写入,写入块地址 —— 0x6BA000,先复制0x6B9000处的七次数据到0x6BA000,再写入第四次的数据 “LittleFS — 366”
写入结束,文件大小6144Byte,存储块在0x783000->0x6BA000处
第四次测试
从文件LittleFS.bin 8192地址处开始,写入四次数据,每次256字节

第一次写入,写入块地址 —— 0x5DD000,先复制0x6BA000处的八次数据到0x5DD000,然后从0x5DD800处写入3072Byte,填充数据到0x5DDFFF,再从0x5DE000处开始,写入本次的数据,然而数据丢失,只写入“?”
第二次写入,写入块地址 —— 0x5DF000,先复制0x5DE000处的一次数据到0x5DF000,再写入第二次的数据 “LittleFS -- 315”
第三次写入,写入块地址 —— 0x5E0000,先复制0x5DF000处的两次数据到0x5E0000,再写入第三次的数据 “LittleFS -- 344”
第四次写入,写入块地址 —— 0x5E1000,先复制0x5E0000处的三次数据到0x5E1000,再写入第四次的数据 “LittleFS -- 376”
写入结束,文件大小9216Byte,存储块在0x783000->0x5DD000->0x5E1000处
第五次测试
分36次,完全读出LittleFS.bin文件内容,对比操作地址与内容,与上面描述一致
总结一下:
1、littlefs文件系统初始化时,会在SPI Flash最开始的两个块中格式化出两个超级块,用于对文件系统的识别及根目录的索引;
2、在建立文件或目录时,littlefs会从超级块中分配一个页用于记录文件的基本信息,并建立文件数据的索引以找到文件的具体数据内容;
3、当文件大小小于一个块尺寸时,尽管文件系统不对超出的部分引索,但其他文件仍然不能使用这个块的剩余部分,所以一个文件至少占用一个块尺寸;
4、如果写入到文件中的数据超过一个块尺寸时,文件系统会在各个块中建立联系,确保数据的联系性,但各个块在物理地址上不一定连续;
5、当在一个文件中追加数据时,文件系统会复制源文件中最后不足一个块的数据到一个新的块,然后在新的块中追加要写入的数据,也就是littlefs的“磨损均衡”;
6、接上边第五条,在数据写入时,littlefs每次都会新开辟一个数据块,然后在新的数据块中添加要写入的数据,即便是对原文件覆盖写入也同样开辟一个新的块,待整个块写满或数据写完时才更新文件索引,让新的数据块在文件链路中生效, 由于数据写入的较慢,而索引更新只需一次写入即可,所以littlefs能实现“断电恢复”。
举报

更多回帖

发帖
×
20
完善资料,
赚取积分