sgreenslade-zb
commented
4 months ago The short answer is that there aren't really any error handling code paths for the backend storage failing. If it's truly a permanent failure of the backend storage (e.g. a block has been lost and cannot be read), this is beyond pretty much any FAT library's ability to do anything. You are allowed to call the readBlock / writeBlock callback with a NULL in the buffer argument to tell AsyncFatFS that the operation failed, but AsyncFatFS will just blindly retry it continually forever. Maybe you'll get lucky and a later retry will succeed.
I've been pondering ways to improve this in my fork, but in the meantime the approach I would suggest to getting a backend storage timeout would be to keep track of the number of timeouts you've gotten and pick a threshold after which you just give up and stop firing the callbacks. This will deadlock AsyncFatFS, but that's hopefully better than pointlessly hammering on dying flash storage forever.
Hello there!
First, I'd like to thank you for this amazing library! It's super helpful!
When sdcard_{writeBlock,readBlock} is called and the operation starts, I get the current timestamp. When sdcard_poll is called I check if the operation has finished in order to call the callbacks, but let's suppose it's taking way too long and something has gone wrong in the layers below the file system (sd card driver or something like that).
In that case, is there a way to tell the filesystem that the operation has failed? As far as I've looked throughout the code base, there is no way, because there's no error callback... What would happen if I were to cancel the operation and mark the SDCard as ready again? I'm assuming I'd lose data...
In that scenario, if I assume the operation is taking too long, is my only option restarting it?
Also, I'm not expecting this code path to be executed, but I'm used to check for timeout in all kinds of operations... just to try and be safe.