UBIFS support for SLC and MLC

[Matthew L. Creech]

On Wed, Jul 20, 2011 at 4:53 PM, John <jtburch62 at gmail.com> wrote:
> I'm exploring flash memory technology for a new product and am
> confused about whether UBIFS fully supports SLC and MLC NAND.  When I
> read the FAQ at
> http://www.linux-mtd.infradead.org/faq/ubifs.html#L_ubifs_mlc, it
> states that one of the two aspects of MLC that are not supported is
> "program disturb".  However, the document link referenced in the same
> FAQ (http://www.linux-mtd.infradead.org/faq/ubifs.html#L_ubifs_mlc)
> states that "program disturb" is common to both SLC and MLC - just at
> different error rates.
>
> 1.  How does UBIFS address the "program disturb" effect in SLC NAND?
>
> 2.  Why doesn't the FAQs explanation for how UBIFS handles "read
> disturb" apply to "program disturb"?
>

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.

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