From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail2.shareable.org ([80.68.89.115])
	by bombadil.infradead.org with esmtps (Exim 4.69 #1 (Red Hat Linux))
	id 1MRBVm-0001SI-Be
	for linux-mtd@lists.infradead.org; Wed, 15 Jul 2009 20:55:39 +0000
Date: Wed, 15 Jul 2009 21:55:28 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Artem Bityutskiy <dedekind@infradead.org>
Subject: Re: UBIFS Corrupt during power failure
Message-ID: <20090715205528.GI3056@shareable.org>
References: <C77C279BA71FD14985DC8E75FB265AB70344D104@usw-am-xch-02.am.trimblecorp.net>
	<1242721105.3623.0.camel@localhost.localdomain>
	<C77C279BA71FD14985DC8E75FB265AB7034DBD10@usw-am-xch-02.am.trimblecorp.net>
	<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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1246854654.20721.271.camel@localhost.localdomain>
Cc: Eric Holmberg <Eric_Holmberg@trimble.com>, linux-mtd@lists.infradead.org,
	Urs Muff <urs_muff@trimble.com>, Stefan Roese <sr@denx.de>,
	Nicolas Pitre <nico@cam.org>, Adrian Hunter <adrian.hunter@nokia.com>
List-Id: Linux MTD discussion mailing list <linux-mtd.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/options/linux-mtd>,
	<mailto:linux-mtd-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-mtd>
List-Post: <mailto:linux-mtd@lists.infradead.org>
List-Help: <mailto:linux-mtd-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>,
	<mailto:linux-mtd-request@lists.infradead.org?subject=subscribe>

Artem Bityutskiy wrote:
> So it indeed looks like NOR erasure includes writing zeroes from the
> end. Unfortunately UBI/UBIFS cannot handle this correctly ATM.

For that chip.  I wouldn't like to assume all NOR chips use the same
erase algorithm.

Also, remember that little problem with the 8-byte write buffer?

I guess it's possible that it's pre-erase-to-zero step might write
zeros in 8-byte blocks too, or in some other size depending on how the
hardware works.  And when it erases bytes in parallel, there's no
guarantee about the order you'll see the bits change if it's
interrupted by a power cycle.

So I guess the right thing is to assume nothing, just that the whole
block may have bits flipped from 1 to 0 in an indeterminate order, and
then all bits flipped from 0 to 1 in an indeterminate order.

Or maybe the weaker assumption, that the whole block is indeterminate
during erase.

-- Jamie