I'm not an expert but you can easily test this by shoving another layer ontop of tcp with more reliability then throw it over an unstable connection and watch the scheduler's buffers overflow until the connection breaks while data transfers stall.
I'm actually ignorant of this, I know of some people who think TCP, and especially its implementation on Linux need to be removed and replaced with something better, but I have done nothing this low on the communication stack. On principle nothing should ever buffer overlow, not even if you run out of memory and storage (you should be prompted to handle it before its an issue).
With flash if the filesystem communicated with the firmware you could also have rollbacks.
Isn't hardware firmware notoriously bad. Really we should have decent hardware I suppose.
>>61
I'm not wise enough yet to respond to this either. Sorry to disappoint.