rtthread中littlefs关于修改大文件内容疑问

Azarik

楼主使用rtthread标准版本开启了DFS组件，以及添加了fal和littlefs，使用的spi flash是w25q64

具体操作流程为挂载spi设备-fal将spi设备抽象成mtd设备-正常挂载文件系统
现在整个结构已经打通，问题出现在应用层上，我有一个930KB的文件，通过open-lseek-write-close这个操作修改开头的192个字节数据，发现close时长居然要有二十多秒，
通过修改READ_SIZE PROG_SIZE以及CACHE_SIZE这些配置均没有变化，通过仿真发现是lfs.c文件中lfs_file_flush函数的while(file -> pos < file -> ctz.size)这个循环占用了大量时间：

            while (file->pos < file->ctz.size) {
                // copy over a byte at a time, leave it up to caching
                // to make this efficient
                uint8_t data;
                lfs_ssize_t res = lfs_file_rawread(lfs, &orig, &data, 1);
                if (res < 0) {
                    return res;
                }

                res = lfs_file_rawwrite(lfs, file, &data, 1);
                if (res < 0) {
                    return res;
                }

                // keep our reference to the rcache in sync
                if (lfs->rcache.block != LFS_BLOCK_NULL) {
                    lfs_cache_drop(lfs, &orig.cache);
                    lfs_cache_drop(lfs, &lfs->rcache);
                }
            }

其中这个file->pos是文件内修改字节的指针地址，这个ctz.size是文件大小，很显然这是一个ctz跳表的程序，
所以问题来了，由于我修改的是文件内开头的几个字节，所以这个file->pos也是指向开头的，但是这个ctz.size是文件最末尾，而这个循环中这个file->pos是逐一自增的，所以耗费了太多时间
请问各位坛友有没有遇到这种情况，或者说如何避免这种情况的发生？