All the data is lost after update from disk 2.0 to disk 2.1

[Maxicu5]

Right after the LittleFS update from version 2.4 to 2.9.1 it has written in debug:

lfs.c:4475:debug: Found older minor version v2.0 < v2.1
lfs.c:4549:debug: Found pending gstate 0x000002000000000000000000
lfs.c:4857:debug: Rewriting superblock {0x1, 0x0}

And everything was ok, then after a lot of reboots, once the reboot happened during a write operation, it has written again:

lfs.c:4475:debug: Found older minor version v2.0 < v2.1
lfs.c:4549:debug: Found pending gstate 0x000002000000000000000000
lfs.c:4857:debug: Rewriting superblock {0x1, 0x0}

and the FS is totally clean after that.

[geky]

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.

[Maxicu5]

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:

1. Run version 2.4 "lfs_format" and create directory structure
2. Update to version 2.9.1
3. Load the FS with a lot of operations creating/removing files and folders (not in root dir, see the "activity" below):
4. Reboot the board in a loop
5. Usually in less than 10 tries it shows that 3 debug messages again and the FS is clean after that.

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.

[Maxicu5]

Attributes are not used.