From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by bombadil.infradead.org with esmtps (Exim 4.69 #1 (Red Hat Linux)) id 1MNgBs-0007TJ-Kn for linux-mtd@lists.infradead.org; Mon, 06 Jul 2009 04:52:51 +0000 Subject: RE: UBIFS Corrupt during power failure From: Artem Bityutskiy To: Urs Muff In-Reply-To: <1246854654.20721.271.camel@localhost.localdomain> References: <1239979018.3390.298.camel@localhost.localdomain> <200905150916.54091.sr@denx.de> <1242721105.3623.0.camel@localhost.localdomain> <1246627562.20721.190.camel@localhost.localdomain> <1246627771.20721.191.camel@localhost.localdomain> <7207AAC68CE347458026863515A07DA102901F3C@usw-am-xch-02.am.trimblecorp.net> <1246629940.20721.219.camel@localhost.localdomain> <7207AAC68CE347458026863515A07DA102901F9C@usw-am-xch-02.am.trimblecorp.net> <1246633131.20721.224.camel@localhost.localdomain> <1246854654.20721.271.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Mon, 06 Jul 2009 07:51:53 +0300 Message-Id: <1246855913.20721.287.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: linux-mtd@lists.infradead.org, Stefan Roese , Nicolas Pitre , Eric Holmberg , Adrian Hunter Reply-To: dedekind@infradead.org List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, 2009-07-06 at 07:30 +0300, Artem Bityutskiy wrote: > On Fri, 2009-07-03 at 17:58 +0300, Artem Bityutskiy wrote: > > On Fri, 2009-07-03 at 08:47 -0600, Urs Muff wrote: > > > I can't find the data-sheet reference to that, but I would not characterize it as 'erasing from the end'. > > > > > > As far as I understand it is a 2 phase process, and you can lose power at any point so you can see a partial phase I or a partial phase II state. > > > - phase I: set all data to 00: a partial picture would be to see 00 at the beginning and random at the end of the block > > > - phase II: set all data to FF: a partial picture would be to see FF at the beginning and 00 at the end of the block > > > > That would be nice, because then UBI would work fine, since it would > > notice corrupted EC header at the beginning, and would drop the PEB. > > > > > From looking at your dumps, it appears that you got interrupted during > > > phase II. I'm not sure why you still have the header, but that might > > > be b/c the block has been reclaimed / reinitialized (I'm not familiar > > > with the actual code, but it appears that way from the dump). > > > > No, I believe it was not reinitialized. > > > > But I should write a small test program which writes a known pattern to > > PEBs, then erases them, and sees what happened to them after an unclean > > reboot. > > [CCed Nicolas Pitre] > > OK, I've written a small user-space program which first fills the NOR > flash with an '0x89ABCDEF' pattern, then starts erasing it, and then > I cut the power at random point. > > And unfortunately the power cut results in eraseblocks which have > 0x89ABCDEF at the beginning, and all zeroes at the end. I've attached > one example. > > So it indeed looks like NOR erasure includes writing zeroes from the > end. Unfortunately UBI/UBIFS cannot handle this correctly ATM. Although I can easily fix this by writing few zeroes at the beginning of the eraseblock _before) erasing it, so that UBI will be happy. But it is still interesting whether I may just ask NOR to amend it's embedded erase algorithm. -- Best regards, Artem Bityutskiy (Битюцкий Артём)