UBIFS support for SLC and MLC

[John]

> I think the first "read disturb" that is discussed in the FAQ is a
> rather specific case: repeated READs of a page cause bit-flips on that
> same page.  The solution is simply to correct the block on-flash
> ("scrub" it) whenever a bit-flip is detected.

Got it.  That makes sense.

> Then there's a more general "read disturb" case, which is called the
> "paired pages" problem in the FAQ: repeated READs of a page (A) cause
> bit-flips on some *other* page (B).  This is trickier to handle,
> because READs may be happening all the time on A, while B isn't
> accessed for a long time.  In that case, the bit-flips on B will have
> a chance to accumulate, potentially beyond the point at which we can
> repair them.  This case is basically the same as the "program disturb"
> case -- it will be handled just fine, but only as long as the pages in
> question are read periodically.
>
> Hence the need for the "flash crawler" mentioned in the FAQ, which
> puts an upper bound on the length of time any flash page will go
> without being read.  As far as I know (someone please correct me --
> and update the FAQ -- if this is wrong), UBIFS itself doesn't
> implement this crawling right now.  So depending on the strength of
> your ECC algorithm, propensity of your flash to experience bit-flips,
> and how often certain parts of the filesystem are accessed, you could
> potentially experience corruption if you've got a filesystem where
> certain parts are read/written often, and other parts sit idly for
> extended periods of time (probably months).
>
> It's worth noting that some of the problems noted from the UBIFS FAQ
> also apply to next-generation SLC.  For example, many new SLC chips
> already require at least 4-bit BCH correction (this used to only be
> the case for MLC).  Their eraseblock life-cycle has also steadily
> decreased (although this is offset by increasing capacities, since UBI
> does wear leveling).  And their tendency to experience problems such
> as read/program disturb has gone up compared to previous-gen SLC.
>
> So the FAQ is slightly out of date in this regard: you may have to
> take many of these issues into consideration regardless of whether you
> go with SLC or MLC.  Hope this helps.
>
> --
> Matthew L. Creech
>

So, in summary, it sounds like UBIFS handles any SLC/MLC artifact that
results in bit-errors on the same page as is being read; but it does
not handle any SLC/MLC artifact that results in bit-errors on pages
other than the one being read.  Do you concur?

(Due to different physical characteristics and manufacturing processes
for older SLC versus new SLC and MLC, I'm ignoring whether the
artifacts are due to "read disturb", "program disturb", or either
combined with "paired pages".)

Thanks,
John