Re: ubi_eba_init_scan: cannot reserve enough PEBs

[Artem Bityutskiy <dedekind1@gmail.com>]

On Tue, 2010-07-27 at 18:12 +0300, Artem Bityutskiy wrote:
> This really does not look like a NAND/MTD driver issue. More look like
> either an UBIFS bug of some kind of corruption which corrupted an EC or
> VID header, then UBI decided to erase this PEB, and then UBIFS reads all
> 0xFFs from there.
> 
> The second theory should BTW be fixed. Indeed, when UBI finds a PEB with
> corrupted headers, it adds this PEB to the 'corr' list, and then just
> erases. But this is wrong! It should erase them only if there are all
> 0xFFs in the rest of the block.

Yeah, indeed looks like a bad bug in UBI. So, when we have some flash
corruptions which corrupt the VID header, UBI just silently erases this
PEB! And then we have small chances to find out why on LEB suddenly
became unmapped (erased).

UBI logic is - if VID header is corrupted, it is because a sudden power
cut while writing the header. And we can erase the PEB because if we
were writing the header, we have not written the data yet.

But it does not bother checking what goes _after_ the header. If there
are some data, UBI should not erase the PEB but preserve it and switch
to R/O mode.

CCing Stefani, I think here group faced a similar issue recently - one
of LEB suddenly disappeared. This may be the reason.

Then the other question - why VID became corrupted? Dunno, but if UBI
won't erase the PEB we'll have better chances to find this out. Does
this sound reasonable?

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)