Re: ubi_eba_init_scan: cannot reserve enough PEBs

[Artem Bityutskiy <dedekind1@gmail.com>]

On Wed, 2010-07-28 at 07:46 +0200, Stefani Seibold wrote:
> Am Dienstag, den 27.07.2010, 18:21 +0300 schrieb Artem Bityutskiy:
> > 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?
> > 
> 
> Not really. Why should especially the master LEB crash?

Not sure, may be there is some reason. Dunno, that was just a thought.

> First: As i understand UBIFS will append data to the master LEBs until
> no space is free, and then it will erase the master LEB and create a new
> one. Is this right?

Yes.

> Second: We need a kind of the patch which i had provided i the case one
> of the master block will be damaged. Otherwise the whole file system is
> garbage.

Yes, but your patch fixes the symptom, unfortunately. It is ok for you
to use as a work-around, but I still hope to find the root cause.