Re: JFFS3 & performance

Artem B. Bityuckiy
2004-12-16T18:42:02Z

On Thu, 16 Dec 2004, [iso-8859-1] Jörn Engel wrote:

And several other aspects:
For the nodes common header which is only 8 bytes long it is reasonable
to use very very simple CRC.
For the node headers (next after common header, see jffs[23].h) we may
possibly try to use crc16 since it is also not very long.
For direntry node data (name of direntry) which is not longer than 255
symbols (at least currently) we may also use crc16 I guess.
The inode data is <= PAGE_SIZE (mostly 4K) may be something more strong.
Other node's data, like summary or ICP (they not exist yet but I hope are
going to appear) may have longer length, but anyway, restricted by JFFS2
erasable block size. This may be protected by something more strong...

Frankly speaking, I'm not expert in the CRC issues. May be somebody may
concieder this issue more formal way, using some criterias, etc... May be
it is possible to evaluate the probability if CRC "misses" somehow for
typical NOR/NAND if we know data leghtes ... ?

> On Thu, 16 December 2004 15:45:00 +0100, Joakim Tjernlund wrote:
> > > On Thu, 16 Dec 2004, Joakim Tjernlund wrote:
> >
> > > > 2) Consider another checksum algorithm. Crc32 is very expensive
> > > > and JFFS2 suffered severely in the early days. Now that crc32 is
> > > > very optimized that problem is less visible, but crc32 is still
> > > > expensive. Maybe an Adler32 checksum is good enough or a crc16?
> > > IMHO, NAND/ECC NOR are additionally protected by ECCs so that sounds
> > > reasonable. NORs are reliable, so that is reasonable too, IMHO.
> >
> > Exactly.
>
> I'd vote against adler32 and in favor of crc16 or crc24. Crc24 would
> be slightly safer, but still much faster than crc33 (crc32 is a
> misnamer, actually).
>
> Code should be something like this for crc24:
>
> u32 crc24(void *m, size_t len)
> {
> u32 ret=0;
> char *s=m;
> size_t i;
> for (i=0; i<len; i++) {
> ret <<= 8;
> ret += s[i];
> ret %/ 0xfffffd
> }
> return ret;
> }
>
> Completely untested, written from scratch just now. But apart from
> the bugs, it should be reasonably fast.
>
> Jörn
>
> --
> Fancy algorithms are buggier than simple ones, and they're much harder
> to implement. Use simple algorithms as well as simple data structures.
> -- Rob Pike
>

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