Re: CONFIG_MTD_NAND_VERIFY_WRITE with Software ECC

[Ivan Djelic <ivan.djelic@parrot.com>]

On Fri, Feb 25, 2011 at 12:59:01PM +0000, David Peverley wrote:
(...)
> Something else to consider - what about bit-flips during writes? These
> are currently only spotted if you enable write verify (and also not
> dealt with or even notified beyond a generic errcode) and ought to be
> handled / notified in a similar manner to the read but it's a lot
> harder to decide how to split this functionality between the MTD and
> FS layers as they're both closely involved. Not everyone wants to
> enable the additional overhead of verifys. Would it be reasonable just
> to leave it to the ECC check on the next read to that block instead?

It is reasonable only if you can guarantee that each page you program belongs to
a properly erased block, and has never been programmed before.

Power failure during erase or programming can produce seemingly erased pages,
but, in reality, unstable pages showing a random (i.e. large), changing amount
of bitflips. At least on recent (<= 50 nm technology) devices.

As of today, the above safety condition is not guaranteed by mtd+ubi+ubifs in
the presence of power failures; in which case enabling write verify is necessary
to avoid data corruption.

> In many ways it would be a lot easier (and involve only a single
> implementation) to provide a config option where if a read or write in
> MTD fails with a (correctable) bit flip or flips that the MTD itself
> takes it on itself to erase the block and re-write the data cleanly.

In order to do that in a safe, atomic way, you need to move data from one block
to another; and to do it in a transparent way, you need some kind of block
management layer, hence UBI...

BR,

Ivan