JFFS3 & performance

[Artem B. Bityuckiy]

Hi Joern,

please, read the paper 
http://www.semicon.toshiba.co.jp/eng/prd/memory/doc/pdf/nand_applicationguide_e.pdf
I like this paper. I've just reread it and now I have no doubts that CRCs 
are required on NAND. :-)

Shortly: errors are normal phenomena on NAND devices. Errors are mostly 
handled by NAND ECCs, but
JFFS[23] MUST take care about failures and handle them properly. There 
are permanent and occasional
errors exist. Blocks with permanent errors must be marked bad and it is 
good to recover data...

On Tue, 11 Jan 2005, [iso-8859-1] Jörn Engel wrote:
> On Tue, 11 January 2005 12:29:33 +0000, Artem B. Bityuckiy wrote:
> > Ferenc Havasi:
> > >If I am right CRCs are not only against the effect of unclean reboots 
> > >but also to handle flash errors. On NAND flashes the ECC handles this
> > >problem but NOR doesn't have any error detection system. 
> > 
> > Joern Engel wrote:
> > >So either we can make sure this case never happens, or we can't.  It
> > >depends on the type of flash, for sure, and it may be pretty hard with
> > >some types.  But if it doesn't work at all, the flash is broken,
> > >period.
> > 
> > Hi, that is really interesting, *why* do we need CRCs in JFFS2?
> > 
> > Do we need CRC *only* to handle unclean reboots? If so, we may possibly 
> > handle it another way, just putting some magic word at the end of node. 
> > Possibly, no need for CRC at all.
> > 
> > Joern stands that if Flash got rotten, we *do not need* to do something 
> > special trying to recover data. Am I right?
> 
> Pretty much.  Detecting the breakage is still a good thing, so we can
> report an error.  There are non-embedded devices with flash and users
> want to see the problem and replace their flash.  But apart from that,
> don't try too hard to fix something that cannot be fixed.
> 
> > I still think we need to do recovery in case of NAND, mark the rotten 
> > block bad and keep working, so we still need CRC. In case of NOR, we 
> > possibly should just report error and do nothing (we can't mark block bad 
> > there). Do not know about ECC NOR.
> > 
> > Comments?
> 
> Ok, here is my approach.
> 
> Claim: No mtd has problems with lost data due to bad blocks.  This is
> a complete non-issue and jffs[23] doesn't care.
> 
> "No" means that less than .001% (add or remove some digits, depending
> on your needs) of all devices have this problem.  In those cases, the
> system just won't work and will be replaced.  Business as usual.
> 
> Now, if any particular flash doesn't match this requirement, the mtd
> driver is supposed to mirror all blocks.  If either copy rots away,
> the data can still be read back from the other block.  After GC, the
> block can be marked as bad and everyone lives on happily ever after.
> 
> Capacity is half the original, but that's better than losing
> /sbin/init now and then, right?  And maybe the flash is cheap enough
> that noone cares.
> 
> Sane?
> 
> > P.S. By the way, we could put CRCs at the end of blocks (*after* data) - 
> > in this case CRC well be extremely strong detecting unclean reboots, isn't 
> > it?
> 
> Interesting idea.  Will make the code slightly messy, but it should be
> worth it.
> 
> Jörn
> 
> -- 
> Do not stop an army on its way home.
> -- Sun Tzu
> 

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.