curaga at operamail.com
Sun Dec 2 10:43:57 PST 2007
> 2007/12/2, Lauri Kasanen <curaga at operamail.com>:
> > 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:
> > 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)->
> 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?
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.
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com
Powered by Outblaze
More information about the livecd