4 ms·

Firmware doesn't update as often though so it'd have to be static wear-leveling. I'm not sure of the safety of doing this with firmware files though - could it

Firmware doesn't update as often though so it'd have to be static wear-leveling. I'm not sure of the safety of doing this with firmware files though - could it actually decrease the life expectancy by moving critical blocks more often? In any case, if 90% of the space is filled with static firmware files then wear-leveling becomes difficult. Probably best to turn it off and let the physical blocks with the logs fail while keeping the firmware blocks intact, or just stop writing logs after a certain point. https://en.wikipedia.org/wiki/Wear_leveling#Static_wear_leveling https://en.wikipedia.org/wiki/Wear_leveling#Static_wear_leve...

e2le 7y ago
Or write the logs to a separate and easily replaceable module/drive. Putting the firmware on the same chip as what you're regularly writing to is probably a bad idea.
mlyle 7y ago
> could it actually decrease the life expectancy by moving critical blocks more often? No. You do normal, dynamic wear leveling. When you notice that the block you want to write to is much more worn than the rest-- say 100 erases extra-- you move a firmware block to it instead and claim that for use. Then that block sits near-quiescent for a long time until it's time to put it back into the rotation of blocks that get actively written. Static wear leveling can just be a tiny, tiny share of write amplification-- a factor of 0.01 or even less-- while keeping all the blocks in play. You only "lose" from static wear leveling if you end up moving something right before it becomes active again. Whatever your strategy, there's always a degenerate write pattern which will cause useless write amplification, but even relatively simple schemes are robust against basically everything except deliberately malicious write patterns, and you can bound this worst case. Incidentally, one way flash fails is by dielectric breakdown increasing leakage causing worn-but-idle-blocks to slowly accumulate error. Moving / occasionally scrubbing static, important data actually helps.

e2le 7y ago

Or write the logs to a separate and easily replaceable module/drive. Putting the firmware on the same chip as what you're regularly writing to is probably a bad idea.

mlyle 7y ago

> could it actually decrease the life expectancy by moving critical blocks more often? No. You do normal, dynamic wear leveling. When you notice that the block you want to write to is much more worn than the rest-- say 100 erases extra-- you move a firmware block to it instead and claim that for use. Then that block sits near-quiescent for a long time until it's time to put it back into the rotation of blocks that get actively written. Static wear leveling can just be a tiny, tiny share of write amplification-- a factor of 0.01 or even less-- while keeping all the blocks in play. You only "lose" from static wear leveling if you end up moving something right before it becomes active again. Whatever your strategy, there's always a degenerate write pattern which will cause useless write amplification, but even relatively simple schemes are robust against basically everything except deliberately malicious write patterns, and you can bound this worst case. Incidentally, one way flash fails is by dielectric breakdown increasing leakage causing worn-but-idle-blocks to slowly accumulate error. Moving / occasionally scrubbing static, important data actually helps.