not enough blocks for JFFS?
Russ Dill
Russ.Dill at asu.edu
Tue Mar 25 14:06:05 EST 2003
On Tue, 2003-03-25 at 05:33, Jörn Engel wrote:
> On Mon, 24 March 2003 19:21:47 -0700, Russ Dill wrote:
> >
> > Your goals would be better served by a user-space solution from what I
> > can tell. Not only would there be less code, but that code would be
> > compressed in cramfs. I'm able to use 1 boot block for blob, another for
> > static configuration, and the remaining two for configuration data saved
> > in this way.
>
> 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
> 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)
> 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
More information about the linux-mtd
mailing list