Re: [PATCH] Newly erased page read workaround

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

On Fri, Apr 01, 2011 at 03:16:01PM +0100, Artem Bityutskiy wrote:
> > That way, the marker is reliable up to 3 bitflips (which is very improbable in
> > the same byte).
> 
> I see.
> 
> I'm curious, if the OOB area is so unreliable, how can we trust it to
> store our ECC? We need a mini-ECC for the ECC then?

The oob area is no different from the data area (same technology).
Fortunately, Hamming and BCH codes (and usual ECC codes in general) actually
have built-in robustness to corruption.

But your point is still valid: when people want to use oob for storing other
things than ECC bytes, say filesystem metadata, they do have a problem; and they
need to make sure that either:
- ECC covers data AND oob metadata (easy to do with BCH, difficult with Hamming)
or
- extra ECC bytes are added to protect oob metadata

YAFFS implements the latter solution.

> > Let us assume Vipin implements the marker idea. He reads a page, and the marker
> > test tells him the page has never been programmed. So he will avoid performing
> > ECC correction on that page. But that page could nevertheless contains bitflips
> > (i.e. not all bytes equal to 0xFF). He could memset page data with 0xFFs to
> > blindly remove possible bitflips, as if the ECC engine had fixed them.
> 
> Ah, I see. Although hiding bit-flips from upper layers might be not the
> best idea sometimes.

I agree, this "blind" cleanup is not such a good idea after all :)

BR,
--
Ivan