JFFS3 & performance

[Jared Hulbert]

> Guess we'll have to agree to disagree then :).  All I know is that I
> want to be damn sure that the data I'm returning isn't totally screwed.
> Call me paranoid.  A checksum is the only way I know of doing that.

Paranoid :)

Checksums may reduce the chance, as Artem says,  of having your device "start
sending private keys of your corporative clients to random addresses" 
because of flash blocks going bad.  Last I checked, read errors were a
very, very improbable event with high quality NOR and besides
checksuming the filesystem won't help protecting us from gamma rays
causing such a problem once the library is in RAM;)

To humor those of us willing to take our chances trusting the media
won't go bad, would it be possible to architect JFFS3 such that
disabling the checksumming or stripping it out is possible with out
too much pain?

Given the performance we get out of even the fastest checksum
algorithms proposed and tested here, it seems checksumming data that
doesn't need it would be a significant performance bottleneck.  I see
this filesystem bottleneck as a big issue when trying to get Linux to
boot really fast, such as for a cell phone.  I understand that most
cell phones have NOR that can be counted on not to have read errors
and that a single successful Linux based phone model could, in matter
of weeks, become the source of the vast majority of running instances
of JFFS2/3 in the universe.  Some would see that as more support for
the need for checksums, but I think it says it's worth adding a
no-checksum option to serve this potential userbase that just doesn't
need the checksums but does need the speed.

I'm not trying to drag on this discussion just for kicks.  In fact I
think it's probably not worth replying to this message, unless there
is something really fantasic and new to add (For example "By George,
he's right!").  I think we all understand each other now.