JFFS3 & performance

[Jared Hulbert]

Clarification on NOR technology.  Remember that the ability to run
code XIP is effectively a requirement for a NOR chip.  This means no
read errors can leave the chip.  I don't see this changing in the
foreseeable future.  Any read errors that do occur would probably be
caused by a failed/incomplete program.

We probably do want to be able to easily retire, reprogram, and/or
test those blocks/pages that get read errors.  That would have to be
done in the filesystem and the chip driver needs to be able report a
read error occured.

Any chance of being able store special files XIP in JFFS3? 
Uncompressed aligned page sized chunks, etc.


,Jared



On Wed, 12 Jan 2005 09:15:42 +0000 (GMT), Artem B. Bityuckiy
<dedekind at infradead.org> wrote:
> 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.
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>