As it stands now there seems to be no 100% reliable way to judge the compressed size of things on jffs2.
I cast my eye to the boot-anim, uncompressed it comes to about 60 Meg, is there space being wasted there? http://lists.laptop.org/pipermail/library/2007-July/000070.html says > JFFS2 compresses 4K chunks using zlib. So it's not just per-file > compression, it's compressing bits of a file. It doesn't compress files > where compression doesn't help. And there's a 68 byte overhead per > compressed chunk. Plus probably some fixed overhead per file. doing some tests using mkfs.jffs2 on a filesystem with a single file of zeros at varying sizes gave me. 409600 --> 11656 819200 --> 23256 1228800 --> 34856 1638400 --> 46456 each growth of 100 4k blocks added 11600 bytes. I'll go out on a limb and say the best case on jffs2 is turning a 4k block into 116 bytes, about 35:1 compression, or down to 2.8% if you prefer This is why the boot-anim bothers me. If it were all zeros it should be taking up just over 1.5 meg. It compresses really well, but it can't go beyond that limit. Running the jffs2size.py script on /usr/share/boot-anim reveals. no compression : 60480336, 60480K estimated jffs2: 1983630, 1983K (3%) mkfs.jffs2 : 2344068, 2344K (3%) zipped : 389259, 389K (0%) .tar.gz : 399360, 399K (0%) .tar.bz2 : 184320, 184K (0%) It looks like there's easily a meg to be had there, two meg looks doable. Where to go from here is another issue. total flexibility and 90% of the size gain could be had by using pngs (not sure if there is a speed issue there) If there were to be a simple runlengh encoding, the bulk of the size would go and jffs2 would crunch the remainder. wadeb whipped up a tiny rle compressor/decompressor pair. gzipping at a file level removes the block overhead and the size drops to about 380k. For smallest size, lzma compressed rle files. appear to be the best. lzma isn't in the default install. It is small at 90k and has potential other user applications. 6325 frame00.565.gz 2283 frame00.565.lzma 15236 frame00.565.rle 1841 frame00.565.rle.gz 1451 frame00.565.rle.lzma 28097 ul_warning.565.lzma 30594 ul_warning.565.rle.gz 22935 ul_warning.565.rle.lzma The final compression method is colour-of-the-bikeshed stuff, the important thing here is freeing up the 2 meg. Whether the actual saving can be1.9MB or 2.2MB is less important. _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel