MLC NAND: all 0xff after erase?

[Artem Bityutskiy]

On Wed, 2012-07-11 at 19:43 +0200, Ivan Djelic wrote:
> Or, conversely, we could decide that erased pages are simply not
> ecc-protected
> (which is the actual truth with many drivers), can contain anything
> (including
> bitflips), and should be signalled as erased and dealt with in upper
> layers... 

I did not not investigate this in details, but I believe UBI and UBIFS
can be changed and they can allow for a number of bit-flips. There are
only few places (may be even 2 - one in UBI and one in UBIFS) which
check if the area contains all 0xFFs. I do not see any obstacles
improving this and implement a smarter functions which would take a
buffer, it's length, ecc step size, and max allowable bit-flips as a
parameter, and check if the page is empty. This could even be an MTD
helper, something like 'mtd_area_is_empty()'.

I think in UBI we only verify if an area is empty in the debugging code,
to make sure we never write over older data. Should be easily fixable.

In UBIFS probably in scanning/recovery code we need to find where free
space starts, probably in a couple of places. E.g., if we are scanning
the journal, and then hit a corrupted node, we want to know if it is the
last node or not. We check this by looking if the empty space starts
after the corruption - in the next min. I/O unit (NAND page), taking
into account the node length.

So I think we only need someone brave enough to implement this.

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120817/e582a69e/attachment.sig>