OESF Portables Forum
Everything Else => Zaurus Distro Support and Discussion => Distros, Development, and Model Specific Forums => Archived Forums => Sharp ROMs => Topic started by: eviLjazz on September 23, 2005, 06:17:31 am
-
Update: Please also check the update further down in this thread...
Hi everybody,
I'm currently experimenting with unionfs and gzipfs on Cacko 1.22. It's working quite good so far.
I'm using unionfs to stack a writeable ext2 filesystem onto a read-only squashfs'ed Debian image. This way I was able to reduce my Debian installation from 270 MB down to just 90 MB and it's still completely functional because all write operations are redirected to the writeable ext2 filesystem.
I'm just now adding gzipfs to this setup to compress the written content, so I only need to update the squashfs image once in a while. Gzipfs doesn't compress as good as squashfs but it's still better than no compression. And because it's also stacked onto an existing file system, everything is a bit more transparent and one doesn't need to waste precious space on a fixed sized image.
Performance is good for both squashfs/unionfs and gzipfs. Actually it seems to be faster reading the compressed files from the SD card than reading plain uncompressed files. I can only guess this is due to the bad SD performance in general.
If anybody wants to check it out, here are the patched sources, patches and compiled modules:
http://www.katastrophos.net/zaurus/sources/ (http://www.katastrophos.net/zaurus/sources/)
Note: I've updated the zlib library in gzipfs from 1.1.3 to 1.2.3 since 1.2.x introduced some performance optimizations.
Further information are available here:
http://www.filesystems.org (http://www.filesystems.org)
Regards,
Andre
-
Cant wait to try this out on my c3K, i have been waiting for this for months
-
I'm currently experimenting with unionfs and gzipfs on Cacko 1.22. It's working really great already.
I'm using unionfs to stack a writeable ext2 filesystem onto a read-only squashfs'ed Debian image. [div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=96770\")
looks great! I was just a bit too scared to start trying this myself.
(previous thread [a href=\"https://www.oesf.org/forums/index.php?showtopic=15119]https://www.oesf.org/forums/index.php?showtopic=15119[/url] )
-
Okay, it turns out, the unionfs version I compiled yesterday wasn't stable. There seem to be some common stability problems with unionfs. Some of them are discussed on the ML:
http://www.fsl.cs.sunysb.edu/pipermail/uni...ber/thread.html (http://www.fsl.cs.sunysb.edu/pipermail/unionfs/2005-September/thread.html)
The current changes in the 1.1 branch (linux 2.6 only) are supposed to fix some of these problems. Thus, I've backported the current snapshot (20050923-1803) of the 1.1 branch to 2.4. This seems to be somewhat more stable, however I got yet another Kernel Oops while doing apt-get upgrade.
Anyway, if anybody wants to try the new stuff, here it is:
http://www.katastrophos.net/zaurus/sources/ (http://www.katastrophos.net/zaurus/sources/)
I need some feedback!
Regards,
Andre
-
Hi everybody,
since Unionfs has some serious issues at the moment, I was looking for some alternatives and found mini_fo:
http://www.denx.de/twiki/bin/view/Know/MiniFOHome (http://www.denx.de/twiki/bin/view/Know/MiniFOHome)
This module does indeed work a lot more stable than unionfs.
Think of mini_fo as a slim version of unionfs that only supports one storage branch and one base branch, whereas unionfs allows to have multiple branches. For my purposes having only one base and storage branch is totally sufficient.
So, this way the compressed Debian in squashfs/gzipfs/ext2fs combo is finally possible.
You can find the compiled module + patches and sources here:
http://www.katastrophos.net/zaurus/sources/ (http://www.katastrophos.net/zaurus/sources/)
Note on gzipfs:
Currently using gzipfs on many small files is bad because gzipfs creates one index file for every compressed file. The problem is, that even if the index files are only 20 byte big, they always consume at least 4 KB (default blocksize) on ext2fs if I'm not mistaken.
So, in turn for many small files the created index files take up more space than was gained by compressing the actual files in the first place.
Now, the idea is to move the index to the end of the corresponding compressed file. Adding a pointer to the index at the beginning of this file should help to get rid of the separate index file.
I'm probably going to hack the gzipfs sources and see how that idea will work in reality. I'll keep you updated.
Regards,
Andre
-
I want to konw how it start when the vmlinuz loaded?