Post
New bug: it appears the write of A to cc8b committed, but the prior write of B to cc8a did not, leading to an inconsistent state where abs(A-B) != 1 (the two values are supposed to be leapfrogging with one always incrementing by two above the other).
This seems to be triggered by an uncorrectable ECC error during a compact operation.
I'm not yet sure how I want to handle this and will need to dump the flash to be sure. One possible option is to, during a compact, ignore all log entries newer than a corrupted entry? That would provide a clean rollback but risks losing data.
Better question is why I wrote cc8b if cc8a hadn't committed fully. Going to have to look at the flash and debug a bit to see what's going on.
0
0
0
So the actual bug here, I think, was that when I got an ECC uncorrectable error during the compact operation, I'd discard the wrong block of data. I think it's fixed, time to fuzz more and see...
I'm definitely making progress squishing bugs, early on I was getting instant failures after only a few seconds of fuzzing and they're now far less common with fairly long time intervals between breakage.
Every so often, glancing at the console, I see uncorrectable ECC errors getting logged but it's successfully recovered in every case with this latest code and the object store remained consistent.
Also found and fixed a bug causing excessive padding to bloat log entries by 8-16 bytes depending on flash write block size. This will break compatibility with existing flash images on STM32L431 but I can live with that given that I only have one project using it on STM32L431 at the moment and the only usage of the KVS is for bootloader firmware revision data.
0
0
0