not enough blocks for JFFS?

[Jörn Engel]

On Tue, 25 March 2003 12:06:05 -0700, Russ Dill wrote:
> On Tue, 2003-03-25 at 05:33, Jörn Engel wrote:
> > 
> > Compressed in cramfs is the point where I really disagree. iirc,
> > cramfs images are a bit larger than jffs2 images. So if you want a
> > read-only rootfs, jffs2 might be a better idea, already.
> 
> not a chance....
> 
> russ:~/src/build$ du -sh out_dir-arm/
> 2.3M    out_dir-arm/
> russ:~/src/build$ ls -l image.*
> -rw-r--r--    1 russ     russ      1286144 Mar 25 12:03 image.cramfs
> -rw-r--r--    1 russ     russ      1364676 Mar 25 12:02 image.jffs2

Correct, my tests disagree with my memory as well. 

> > Especially, if you need some if the jffs2 functionality again to save
> > configuration data. I doubt that you would save a lot with userspace
> > code + cramfs versus jffs2 both in flash and in memory consumption.
> 
> cramfs.o is 7662 bytes, jffs2.o is 74046 bytes. cramfs requires almost
> no kernel allocated memory to run, jffs2 creates large data structures
> to keep track of nodes. A simple userspace implementation to read and
> write nodes to flash that include crc's and revisions in 4296 bytes
> (object file before linking)

Also correct. Over here, jffs2 accounts for 45k of zipped kernel
image, cramfs for 15k. Both numbers include zlib (not shared).

> > Time might be spend better in improving jffs2, than in reimplementing
> > a subset of jffs2's functionality each time.
> 
> A userspace library would be nice

Agreed.

Your suggestion still doesn't apply to my problems, but it would make
more sense for Tim.

Jörn

-- 
Good warriors cause others to come to them and do not go to others.
-- Sun Tzu