mtd/fs/jffs2 erase.c,1.84,1.85 roll back

[Jörn Engel]

On Mon, 26 September 2005 12:03:17 +0400, Artem B. Bityutskiy wrote:
> Jörn Engel wrote:
> >On Fri, 23 September 2005 17:22:53 +0200, Anders Grafstrom wrote:
> >
> >>jffs2 makes a second try if a failed erase is reported by the mtd 
> >>driver. But only for NAND (in jffs2_write_nand_badblock()). What I'm 
> >>after is a retry for NOR as well. But I wrote the patch so it would 
> >>retry for other cases of failure too.
> >
> >Is a retry really an improvement?  When a block cannot be properly
> >erased on the first try, I would not trust it anymore.  Instead of a
> >retry, I'd rather mark it as a bad block and not touch it again.
> 
> From the other hand, why not to retry? Does it hurt? Is this in the 
> critical code-path? Deity knows what happend to the hardware/driver, may 
> be there was a short magnetical disturbance and that was the reason why 
> the block was not erased. May be one of the lines/cirquits outside of 
> the flash was affected but the block is really erasable. Actually, after 
> I've read the paper that *you* pointed 
> (http://www.cs.wisc.edu/adsl/Publications/iron-sosp05.pdf), I'm rather 
> positive about the idea of retrying. The articlae is about HDDs, but IMO 
> is also acceptable flash devices in this respect.

Depends on where the problem is.  An alpha particle messing up the bus
- sure, just retry and it'll work.  Something in the flash - by all
chances the block is messed up and shouldn't be used again.

As a default, I'd consider the block in question to be dead.  I don't
mind a retry per se, but that should be the exception.  If the first
retry didn't work, you can be pretty sure that it was not just an
alpha particle and should declare your hardware dead.  It doesn't even
matter whether it's the flash, the bus or anything else.

Jörn

-- 
Ninety percent of everything is crap.
-- Sturgeon's Law