Open Maxicu5 opened 2 months ago
Does "Expanding superblock" occur in your log at all during this? If so #953 may be related (currently unsolved).
What is most likely happening is something is corrupting one of the superblocks, causing littlefs to find/mount the older superblock.
It's unlikely this is actually related to the commit that changes the version, most likely other state is rolling back as well.
It would be very useful if you're able to reproduce this with a small example somehow.
Also what is your config? block_size, block_count, block_cycles, etc? This is useful for looking for patterns with other bug reports.
No, there was no "Expanding superblock" message in the debug log. The only messages I have reported above. 3 right after the update, and the same 3 after one of a lot of reboots. Steps to reproduce:
The activity: Actually, it is "log" system, which writes up to 10 files 40kB size each, in "/log/[timestamp].log" files, when 10 files are written, it renames/moves them into "/log/archives/[number]/[timestamp].log" files, the number is incremented. And it continues to write the new ones into the "/log/[timestamp].log". Once per 30sec, it checks "lfs_fs_size", and if there is less than 1MB free left on the FS, it removes the oldest "/log/archives/[number]/[timestamp].log". When the oldest folder "/log/archives/[number]" is empty it is also removed. Test is running when FS is full, so entire set of writing functions is in use.
The config:
.read_size = 1,
.prog_size = 1,
.block_size = 4kB,
.block_count = 2000 (8MB),
.block_cycles = 100,
.cache_size = 256,
.lookahead_size = block_count/8,
.name_max = 24,
.file_max = 0,
.attr_max = 0,
.metadata_max = 0
All the new fields in 2.9.1 were set to 0.
Attributes are not used.
Right after the LittleFS update from version 2.4 to 2.9.1 it has written in debug:
And everything was ok, then after a lot of reboots, once the reboot happened during a write operation, it has written again:
and the FS is totally clean after that.