JFFS3 & performance

[Artem B. Bityuckiy]

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.