RFC: detect and manage power cut on MLC NAND

[Ricard Wanderlof]

On Wed, 11 Mar 2015, Jeff Lauruhn (jlauruhn) wrote:

> IIUC can I summarize like the following
> 
> 1) power cut is one of the big problem we know about MLC NAND flash with UBI
> 2) we are unaware of other big issue with MLC NAND
> 
> Unfortunately I don't really know the MTD/UBI/UBIFS internals but 
> (correct me if I'm wrong) to me solving the power cut issue only by 
> software (by using proper data structure, redundancy, NAND flash 
> operation jornal and so on) is pretty hard to implement inside the Linux 
> MTD stack.
> 
> On the other hand, stuff like scrubbing (e.g. having a task like GC that 
> periodically scrub the required NAND erase block), paired page (e.g. 
> carefully selecting LEB to PEB mapping to avoid reading/writing data 
> into paired page in a wrong way) are still to be implemented but have, 
> somehow, less impact on the whole MTD stack.

I may be going off in the wrong direction, but there seem to be two 
principal differences between SLC and MLC nand from a software point of 
view.

1. Write endurance is much lower, like 3000 erase/write cycles for MLC
   compared to 100000 for SLC.
2. The probability of bits changing 'under your feet' are much higher,
   being it because of the data retention simply being worse due to the
   underlying technology or because of page pairing.
   - This also includes bits that look ok but which aren't e.g. from the
     result of power loss during an erase operation, which might leave
     the bits in a state which looks erased, but which on subsequent use
     will not behave accordingly.

Generally, the basic view of any memory from a software point of view is 
that if 'the data was written it will not change', which is true a lot of 
the time with SLC, given a couple of precautions (like ECC and never 
trusting an erased page unless we know the erase operation had completed 
properly), but much less so with MLC. I.e. with SLC, we can take our 'the 
data will not change' paradigm and patch on a few fixes for the relatively 
few cases where this is not true, but with MLC this will approach will 
tend to fall apart and we must rethink our approach if not from the bottom 
then a bit further down than was the case with SLC.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30