DSL Ideas and Suggestions :: squashFS
Noticed an interesting article bencmarking squashFS on Kerneltrap...
http://www.kerneltrap.org
performance numbers are here...
http://kerneltrap.org/files/PERFORMANCE.README.txt
The interesting bit mentions DSL...
"2. Damn Small Linux liveCD performance tests
ext3 uncompressed size 126 MB
CRAMFS compressed size 52.19 MB
Squashfs2.0 compressed size 46.52 MB
Squashfs2.1 compressed size 46.52 MB"
Looks like it might give us an extra meg or two and be faster all round as well.
:-)
cool ,maybe can be implemented in dsl
More space, more options for dsl.
sorry for my english
coooooooooooooooooooooooooooool, what more can i say. we can have scite back, chatzilla, fireftp and tons of other really really coool stuff.
although the drivers might take up space.
using Knoppix 3.4's .config file and the linux-2.4.27 sources, along with the squashfs2.1 patch, I'm currently building a squashfs.o for testing on DSL. If all goes well, we'll be able to use squashfs.
On the other hand, I thisnk it might be better to keep KNOPPIX as a cloop. I'll explain later.
Meanwhile, why I want squashfs:
The primary obstacle to having LOTS of applications in a MyDSL CD is ram. Especially on older machines, if you've got less than 128M, you're pretty much up the crick.
One could repackage the key applications as cloop files, but then you've got a system limitation of seven bits of software (/dev/cloop1-/dev/cloop7. /dev/cloop0 (or simply /dev/cloop) is occupied by KNOPPIX).
But with squashfs, you are NOT limited to the number of cloop devices. I don't know what the maximum limit is, but I'll be trying to find out.
Meanwhile, with squashfs, it's possible to make MyDSL occupy almost NO EXTRA RAM PER PACKAGE. I'll explain:
I don't know if you're quite getting me here, so I'll put it together:
Create a squashfs file containing, say, gaim.dsl (expanded into position, of course). The /home dir would be packaged in user.tar and placed in the root of our squashfs.
This is the "new-format" package I'm hoping for.
The user downloads that file.
The system runs mkwritable (4M overhead). In my vision, it would run mkwritable upon boot.
The system then mounts it in /opt/gaim, and symlinks its contents, omitting user.tar (no .gz, as the file is already compressed and the gz headers would increase the total image size) to their analogues in the filesystem. user.tar is expanded to your /home dir.
You now have gaim. gaim is not occupying ANY RAM (well, some for user data, but not much). Install a few more sqfs-type packages, still very little extra RAM use.
I'll have more info on this once I've experimented more.
Meanwhile, I'm supposed to be rewriting mydslmkr as a local perl/shell app (maybe with a bit of C thrown in there too if serenary).
I'll post updates as the occur.
Next Page...
original here.