I just realized, that upx also support mips/mipsel/arm... and i assume the compression of upx is better than the fs compression. would it make sense to compress larger files (perhaps > 50k) with upx, or would this result in a overhaed because of the double compression (upx and fs)?

cheers
michu

edit:
just compressed busybox (kamikaze 7.09):
658987 ->    285144   43.27%  linux/mipsel   busybox

(Last edited by michu on 17 Mar 2008, 10:16)

Why? There are better routers with more flash and RAM...

I use a asus wl 500gp with 8mb of flash... but im slowly running out of free flash space and I dont want to store my apps on a external memory stick nor hdd...

Both squashfs and jffs2 are compressed, so pre-compressing the packages with UPX doesn't make sense..

i know that.. but my *guess* was, that upx has a better compression ratio than the on-the-fly jffs2 compression. so this would make sense when using large application? does jffs compress the file, even the compressed file is larger than the uncompressed file?

And from where do you take the CPU horsepower for decompressing? The CPU of most consumer routers is already too slow to route 30mbits...

(Last edited by forum2008 on 17 Mar 2008, 11:20)

well I guess i give it a try... of course there is a tradeoff between cpu and diskspace, but loading a daemon one and saving 30% diskspace (just a wild guess) may be worth it... I'll check it

Besides, some of us don't have anywhere close to 30mbps Internet connections.

Although I think using upx is probably more trouble than it's worth.

disk free BEFORE upx:

root@OpenWrt:/# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/mtdblock3            5.7M      5.2M    468.0k  92% /jffs

disk free AFTER upx:   

root@OpenWrt:/# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/mtdblock3            5.7M      5.0M    676.0k  88% /jffs

-> more than 200k are freed!

I compressed those files

     81219 ->     28828   35.49%  linux/mipsel   bemusedlinuxserver
    245730 ->     96996   39.47%  linux/mipsel   bluetoothd
    378051 ->    131244   34.72%  linux/mipsel   dbus-daemon
    268111 ->     95564   35.64%  linux/mipsel   hcid
    250987 ->    104900   41.79%  linux/mipsel   pppd
    371891 ->    105740   28.43%  linux/mipsel   strace
    159319 ->     60876   38.21%  linux/mipsel   lcd4linux
     61259 ->     23708   38.70%  linux/mipsel   mpc
    217639 ->     82700   38.00%  linux/mipsel   mpd
     67787 ->     22276   32.86%  linux/mipsel   sdptool

the funniest part is the execution time:

root@OpenWrt:/# time mpc.nonc
Morcheeba - Washed Away (Feat. Thomas Dybdahl)
[playing] #43/88   0:28/4:22 (11%)
volume:100%   repeat: on    random: on
real    0m 0.45s
user    0m 0.00s
sys     0m 0.01s

root@OpenWrt:/# time mpc
Morcheeba - Washed Away (Feat. Thomas Dybdahl)
[playing] #43/88   0:30/4:22 (11%)
volume:100%   repeat: on    random: on
real    0m 0.34s
user    0m 0.01s
sys     0m 0.01s

mpc.nonc is the uncompressed file! perhaps its faster due less reading on the slow flash?

so my opinion is that upx is not that stupid... what you think?

You forgot something - with "ls" you will hardly see the size of the files they take on the disk, as that will show the uncompressed size (jffs2 compresses on the fly).  Instead of this, one could start with an empty jffs2 (eg. right after reflash), and compare the output of df -h after installing only the uncompressed or only (after another reflash) the upx compressed binaries.

ok... aren't there any jffs2 tools available? for example a tool like jffs2info /path/file - outputs size on disk.

so you mean, a df -h outputs only the uncompressed files size and not the actual free space on the disk? this means if df shows there is 100k of free space, its possible to install (for example) 150k due compression?

Exactly, but you can't really predict the compressed size.