> 2007/12/2, Lauri Kasanen <[EMAIL PROTECTED]>: > > Hi > > > > I'm looking into the various livecd techniques, how to pretend > > r/w, compression.. > > I just looked at the latest 6.3-min cd. I understood most of it, > > but have some questions left: > > > > In the past Alexander told me: > > > Cloop was never used on LFS LiveCDs. Older CDs used squashfs for > > > compression, while modern CDs use zisofs. The change was done because, > > > with device-mapper based RW mechanism, one has to compress a single file > > > (root.ext2), not a full filesystem tree, and both zisofs and squashfs > > > are equally efficient for that - but zisofs is simpler to set up. > > > > Why is this so? > > Because device-mapper needs a single block device (say, loop), and > loop needs a single file, not a filesystem, to be attached to. > > > There isn't much documentation on device-mapper available.. > > I used this article when implementing a LiveCD: > http://linuxgazette.net/114/kapil.html > > > Why couldn't a squashfs file be used as the first loop device? > > A squashfs file can be loop-mounted and produces a filesystem (i.e., a > whole tree). Device-mapper expects a block device, not a filesystem, > as its input. > > So yes, you can produce a squashfs file containing a filesystem with a > single root.ext2 file that you can use for a loop. Thus, you are > proposing this: > > isofs -(mount)-> compressed.sqfs -(loop)-(mount)-> root.ext2 -(loop)-> > device-mapper > > while the CD uses this simpler setup: > > zisofs -(mount)-> root.ext2 -(loop)-> device-mapper > > Note no mount between root.ext2 and device-mapper in both cases, while > squashfs produces usable compression only when loop-mounted. > > > 2) How did you come up with the overhead calculated? > > I guess it's used to have a little bigger writable area than the > > original even if there's less ram than the livecd size available, > > correct me if I'm wrong.. > > I made a device mapper snapshot setup with two loops over sparse > files, with the second file being too large, and filled the resulting > device with junk. Then I looked how much of the second file was > actually filled with data. This way, I can guarantee that the snapshot > won't go offline even if a user erases everything from the LiveCD > filesystem and fills the resulting empty filesystem with completely > different data. > > Of course, this is overkill. If you create the second file with only > 256 MB size, the snapshot won't go offline until the user actually > writes a bit less than 256 MB. > > And yes, it is possible to fill the RAM completely by creating files, > if the computer has less than 1.5 GB of RAM. > > > 3) What's the minimum amount of RAM needed to boot the LFS > > livecd? By my tries in qemu it's somewhere between 20 and 30mb, > > as 22 didn't boot and 30 booted. > > Yes, this is a reasonable estimation. > > > Is this because the > > initramfs file is 15mb uncompressed? > > Yes.
Thanks, this clears up a lot. For using squashfs, I just thought it is overly complicated to modify many areas of an iso when booting toram, but when using squashfs the file could just be copied into tmpfs. Lauri -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze -- http://linuxfromscratch.org/mailman/listinfo/livecd FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
