关于littlefs文件系统的效率问题

发布于 2019-12-26 14:11:33 浏览：9287 订阅该版

17 个回答

通宵敲代码 2020-01-03

这家伙不懒，他只是什么都不想写

为了验证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 -- %d\n",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 -- %d\n",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文件内容，对比操作地址与内容，与上面描述一致

附上测试过程输出的日志文件，感兴趣的可以看看
[attach]13098[/attach]

## 总结一下：
1、littlefs文件系统初始化时，会在SPI Flash最开始的两个块中格式化出两个超级块，用于对文件系统的识别及根目录的索引；
2、在建立文件或目录时，littlefs会从超级块中分配一个页用于记录文件的基本信息，并建立文件数据的索引以找到文件的具体数据内容；
3、当文件大小小于一个块尺寸时，尽管文件系统不对超出的部分引索，但其他文件仍然不能使用这个块的剩余部分，所以一个文件至少占用一个块尺寸；
4、如果写入到文件中的数据超过一个块尺寸时，文件系统会在各个块中建立联系，确保数据的联系性，但各个块在物理地址上不一定连续；
5、当在一个文件中追加数据时，文件系统会复制源文件中最后不足一个块的数据到一个新的块，然后在新的块中追加要写入的数据，也就是littlefs的“磨损均衡”；
6、接上边第五条，在数据写入时，littlefs每次都会新开辟一个数据块，然后在新的数据块中添加要写入的数据，即便是对原文件覆盖写入也同样开辟一个新的块，待整个块写满或数据写完时才更新文件索引，让新的数据块在文件链路中生效， 由于数据写入的较慢，而索引更新只需一次写入即可，所以littlefs能实现“断电恢复”。