From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-fx0-f49.google.com ([209.85.161.49]) by bombadil.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1OnC5s-00062J-Dk for linux-mtd@lists.infradead.org; Sun, 22 Aug 2010 15:04:21 +0000 Received: by fxm12 with SMTP id 12so3092592fxm.36 for ; Sun, 22 Aug 2010 08:04:19 -0700 (PDT) Subject: Re: ubi_eba_init_scan: cannot reserve enough PEBs From: Artem Bityutskiy To: Stefani Seibold In-Reply-To: <1280296009.4310.5.camel@wall-e.seibold.net> References: <1280121714.14917.40.camel@localhost> <1280243535.3021.29.camel@localhost.localdomain> <1280244117.3021.36.camel@localhost.localdomain> <1280296009.4310.5.camel@wall-e.seibold.net> Content-Type: text/plain; charset="UTF-8" Date: Sun, 22 Aug 2010 18:04:16 +0300 Message-ID: <1282489456.16502.74.camel@brekeke> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: "Kreuzer, Michael \(NSN - DE/Ulm\)" , linux-mtd@lists.infradead.org, "Matthew L. Creech" Reply-To: dedekind1@gmail.com List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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.