Hi!
I just ran some tests on several compressed filesystems, and it turns
out that cloop has the worst performance in terms of caching of all of them.
Compressed filesystems gain space in a Live CD, but also speed because
less data has to read from the physical medium, and reading the CD itself
is usually the bottleneck.

Klaus once said:
zisofs is a compressed filesystem, cloop is a compressed
block device. Compressed filesystems are slower, because
each file has to be uncompressed again in each read, while
cloop keeps the uncompressed blocks in the normal block
layer filesystem cache. cloop is older, well-tested and
filesystem independent.

But, unlike all the other compressed read-only filesystems, cloop re-presents
a file that lives on the native CD filesystem as a new uncompressed filesystem,
and this means that the data are buffered twice: once in compressed form when
they are read from the native CD filesystem and once again after decompression.

To test this theory, I took a machine with 500MB RAM, got as much free RAM as
possible by running a 500MB process and killing it, got the tools (bash, tar, cat and
vmstat) into memory and then tarred up /opt from Knoppix 3.6 into /dev/null.
To read a total of 231380K it filled a total of 332548K of extra cache.

Now I don't know whether the cmpressed filesystems cache their data in
compressed or uncompressed form, but cloop caches it in both!
Apart from the fact that cloop does not give the best compression of the
full-feature compressed filesystems (squashfs was the best at that, sorry,
I don't have the figures to hand) cloop also beats the cache to death, and on a
memory-limited system, effective use of RAM and caching makes a big
difference to system performance.
And I would argue that for running a LiveCD most users are more
memory-limited than CPU-limited. 500MHz 128MB systems are common.

What about it, Klaus? ditch cloop? :)

M