littlefs
littlefs copied to clipboard
littlefs-project
Data sometimes reads incorrectly after lfs_seek unless a rewind, sync, or second seek is executed first.
For an embedded system project at my day job we've found a regression in v2.5.0 that is not present in v2.4.2.
The symptom is that data sometimes reads incorrectly after an lfs_seek, unless either a rewind, sync, or a second seek (to the same location!) is executed first.
We've put together a completely stand-alone reproduction case that demonstrates this with v2.5.0, shows that the bug goes away if you use several workarounds, and also demonstrates that this issue does not occur with v2.4.2. This example just uses memory as mock storage so this can run easily on a host PC, but we found this bug when targeting a real non-volatile memory device that uses these specific settings.
This is a zip file that includes the reproduction program along with a simple makefile and snapshots of LFS v2.5.0 and LFS v2.4.2 that this tests against.
This text file shows the output we get when running this test.
Some things we noticed right away are:
- The error seems to always (or at least usually) occur when the previous file position is at certain specific values, like 252 (interesting because our block size is 256 and we're doing 4 byte reads in this test).
- It seeks to mostly happens when the current file position is a certain value in relation to the previous file position; we suspect something to do with the caching system, but we're haven't attempted to debug LittleFS itself at this point.
- It appears to happen in "bursts". That is, if one read is was, the next read is also likely to be bad. (Again, makes us suspect something with caching.)
Anyway, hope this helps you find and fix this bug. I've used LittleFS in the past and always found it very robust, but we always stress test 3rd-party code and finding this issue was quite a jarring experience. For now we're probably going to move back to v2.4.2 and we'll certainly let you know if we find any other issues. =)
