Jochen Kunz wrote:
> On Mon, 20 Mar 2006 22:29:12 +0100 (CET)
> Hubert Feyrer <hubert@feyrer.de> wrote:
>
>   
>> ``Squashfs is a compressed read-only filesystem for Linux''...
>>
>> Is this like vnd(4) with VND_COMPRESSION?
>>     
> No. vnd(4) presents a block device to the upper layer, does optional
> compression inside and uses a file on an other file system as backing
> storage. squashfs is a file system like ffs or lfs that risides on a
> block device. The difference is that it is read only and does
> compression on all data and I think metadata too. In the Linux world
> squashfs is usefull e.g. as file system for the initrd too. squashfs
> claims to be very space efficient. To my experience a squashfs image of
> a directory tree is only a few % bigger then a tar.gz of that directory
> tree.
>
> OpenWRT uses a squashfs to store the firmware. This squashfs is mounted
> as root. Later it is remounted on /rom and a JFFS2 is mounted on root.
> The JFFS contains only links to /rom. e.g. /bin/ls -> /rom/bin/ls. This
> makes the system more robust. If the JFFS2 gets garbled and can't be
> mounted, the kernel / init script on the squashfs just reinitializes the
> JFFS2 from scratch at the next boot.
>   

This is great when there is enough *RAM* to host the root filesystem. 
Often this isn't the case.  For instance, one device I'm dealing with
has 8MB RAM, and ~4MB flash.  Not a pretty situation, of course, but it
*can* be made to work for very limited things.

Even given larger sizes, you don't really want to waste your RAM housing
both the squashfs and the uncompressed binaries.

    -- Garrett

> AFAIK JFFS2 has problems with big filesystem sizes. Garrett pointed out
> this already. It needs very long to mount large file systems. At $WORK
> we need a flash file system for flash devices in the GB range and JFFS2
> faild because of exorbitant delays when the device gets mounted. (IIRC
> it was somthing like O(n^2) where O is mount time and n is the FS size.)
> You may call JFFS2 on multi GB devices abuse, as it was designed to run
> on flashs with only a few MB size to store some bits of firmware and
> config data.
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191