I could add a little disk format version field in the page state I think. That could be nice to have. Not sure.
At least there could be a (runtime) error for version mismatch. But that has to be bitflip resistant too, just like the rest of the code.
Half a page state is at worst just one byte. 2 bits minimum are used for the state, so there's 6 bits left. Double up every bit and you have 3 bits or 8 versions.
So maybe just a parity bit? Then there's 5 bits for 32 versions. At this rate s-s could then support 80 years of development
Btw, I won't be maintaining two disk versions *for free*. The equation changes if the extra work is paid for.
So ehh, hit me up if that sounds attractive. There could even be slow transition where old pages are read using the old format and new pages are written in the new format
@diondokter My vision for long-term upgrades is still more rooted in how I think firmware updates should work:
* There's a small (minimum 1 page, checksum'd, can't upgrade while that's dirty) area that is persisted through firmware updates.
* While live, a firmware can go crazy smart with journaling, wear leveling, whatever.
* When it's time to reboot with intent to switch firmware, the running firmware writes the (simpler) small config area.
* The next firmware picks things up there.
@diondokter As a bonus, once the new firmware has received the OK to engange rollback protection, it can use the whole image B area for wear leveling. (Compating to the single page is still not an issue because In My Perfect Little World, storage structures are all sized at build time, and under-utilizing them is a wear-leveling optimization only).
@chrysn Yes, that makes a lot of sense!
I've done something similar where we'd just revert to (new) defaults for most things on firmware upgrade and save the critical user config on a single page (which almost never changed).
But not everyone has the foresight and don't have anything that can recover from format changes