-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shutdown strengthening #16
Conversation
Not sure if anybody's watching this space... Ideally yes, but that'd be very annoying to implement... |
…its own incorrect one
@diondokter I like the repair function, very nice improvement. I think leaving it up to the user is better and feels more in line with the rest of the API to be honest. Perhaps a rustdoc comment on the Corrupted enum variant pointing to the try_repair would be sufficient? |
Ok, cool. I'll do that then. But I got snagged by multiple writes on flash. So... I'm gonna have to spend some time to fix that, if that's even possible. |
…h an adapted crc to fix the multi-write issues
Cool! I was able to fix it without doing major changes :D |
…shutdown versions were a superset, so the old are not necessary anymore.
Find item now skips forward a full item header instead of just a word when it encounters corruption. This makes things more consistent.
Turns out it's actually useful to fuzz in CI! Otherwise I'd already have merged it :P |
@diondokter I've been testing the repair function a bit now, and I wanted to ask about a behavior I'm seeing in my initialization process, sssuming I've written gibberish to the queue partitions before startup:
The error in particular is "Corrupted: All pages are closed", which suggests it haven't realy repaired/erased anything. |
In particular it's caused by the find_youngest_page at the end of the function:
I'm wondering if there is a condition here that the repair doesn't fully fix. Perhaps it should check the for this condition as well and return an error in that case? This would make the use of the API a lot smoother, since you can trust try_repair to give you an error if something is wrong rather than trying to use the flash. |
Ah I see. I designed the repair function so it can repair the state if it got reasonably corrupted from a previous correct state. So right now the repair function is only repairing things that result from an unexpected shutoff with the assumption that bytes are written from start to end every transaction. In your case, if you follow the documentation, you should end up with erasing the flash yourself so you start fresh again. I guess that checking the flash for errors in the repair function would be nice for users, but there are so many things that could go wrong it'd be difficult to check them all. |
Alright, thanks for explaining, that makes sense! |
Using the fuzzer to simulate a power shutdown and adding a repair function that can solve it.