JFFS3 & performance

[Thomas Gleixner]

> Claim: No mtd has problems with lost data due to bad blocks.  This is
> a complete non-issue and jffs[23] doesn't care.

NAK 

NAND and ECC'ed NOR FLASH have a implicit property of occasional
bitflips, which are related to various causes. The ECC addon in the
chip/technology driver takes care of that and may even be able to
recover the resulting data loss. 

ACK

NOR is significantly less prone to data loss and bit flips, so I agree
here to the extent of the following paragraph

A flash aware filesystem has to be aware of failure sensitivity of the
devices they are dealing with. An additional constraint is that FLASH
filesystems are normally used in systems which have totally different
environments and constraints than a desktop system.


> "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.

Mirroring is not a complete solution to address the various
requirements. It's one out of many mechanisms which you might be able to
sell to some of your audience.
Moving the responsibility to a different layer is a real bad idea, as it
restricts the implementation of other filesystems on top of the same MTD
technology. e.g. YAFFS deals nice with NAND oddities and I totaly refuse
to restrict the usage to a subset of capabilities. If your
implementation decision is to use mirroring then provide is as a
seperate feature/layer, which can be used on request.

Facts: 

- FLASH devices are error prone. The grade of proneness is depending on
the FLASH technology
- Devices have partially standardized mechanisms of error correction

Problem:

- Develop a filesystem aware of the above constraints
- Do not overemphasize error correction/protection/ in favor of
performance and depending on FLASH technology
- Make it DAU (For non native german speakers: Dumbest Assumed User)
safe 

Incomplete solution requirements:

- Be aware of the error proneness you are dealing with
- Utilize the error correction / detection mechanisms and deal with the
information they provide. 
- Provide additional userspace fallback mechanisms and design patterns
which help to improve the failsafe goal

> 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?

Especially high volume systems are very sensitive to the price aspect.
For them it is cheaper to invest in software development than adding an
additional 1$ to the hardware.

tglx