Quote Originally Posted by kl522 View Post
I think the claim that cloop needs at least I G memory is likely to be over-stated. A quick check on cloop source code revealed that it also decompresses the file system on-the-fly basis.

The 1G of /ramdisk mounted, used when one does not have persistent store, is something which the actual usage will grow as it is used. The 1G /ramdisk is mounted, but not used when there is a persistent store. And therefore even though that's a "bug", it does no harm.

In terms of CPU cycles, there is no apparent difference between squashfs and cloop, because both uses the same "on-the-fly" decompression and buffered blocked strategies, and also same compression algorithm.

Therefore the only different between squashfs and cloop is that squashfs has long been accepted into the kernel, it needs no extra maintenance. Cloop is currently maintained separatelly by the author of KNOPPIX.
I don't think Klaus would have become the maintainer of cloop for anything less than a substantial reason; too much work for no real benefit. I don't know what that reason is, but I know it must exist. The "phantom GB of ramdisk" aspect of cloop is probably intentional, perhaps to make possible very fast growth of the actual filesystem, or some such. Regardless of all that, if one had some reason to avoid using the compressed filesystems (perhaps speed?), how difficult would it be to leave that out in a re-master? Just curious, and I thought one of y'all might have the answer.

Cheers!
Krishna