Squashfs-ed knoppix

[kl522]

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.

[krishna.murphy]

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

[kl522]

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.

That's what we call "belief", it's not based on facts.
I think it's all historical. Cloop existed long time ago. Klaus is not the creator. He is just the maintainer. He needed it at that moment. So now nobody else except him has "vested" interest in it. He is using it simply because he is familiar with it. Kind of sentimental value thingie. As a matter of fact, it's a easy swap to use squashfs.

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.

I believe that you said this because you did not look at the code. The ram disk has nothing to do with cloop. The ram disk is created for unionsfs with cloop, to allow users to have write access to the otherwise read-only cloop. And it's left mounted unused when the user has a persistent store. If you look at the code you will agree with me, it's a bug.