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

建议用fal 转mtd，我用的好像速度没问题

为了验证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能实现“断电恢复”。