[Fedora-livecd-list] Revised: [PATCH] turboLiveInst - improves livecd/usb installer speed by 15-20+%

Mark McLoughlin markmc at redhat.com
Tue Sep 4 08:49:17 UTC 2007


On Mon, 2007-09-03 at 15:33 -0500, Douglas McClendon wrote:
> Mark McLoughlin wrote:

> > 
> > 	The main suggestion I'd have is that if the osmin.size was dropped[1],
> 
> Actually in my first iteration of the patch, I was using dumpe2fs, but 
> my parsing of it with awk and grep looked pretty ugly.

	Something like this is nice and simple:

    import commands

    def parseField(output, field):
        for line in output.split("\n"):
            if line.startswith(field + ":"):
                return line[len(field) + 1:].strip()

        raise KeyError("Failed to find field '%s' in output" % field)

    (status, output) = commands.getstatusoutput("/sbin/dumpe2fs -h /dev/root")

    print parseField(output, "Block count")

> > and if we could reduce the size of the COW area of the snapshot to its
> > minimal (i.e. look at how much is used and truncate it at that point),
> 
> This is pretty easy.  In the intervening time, I am now confidently 
> aware that I can use dmsetup status on the snapshotted device to 
> determine how much of the file can be truncated.

	Yep.

> > then we can just include osmin.img directly and cut out a lot of the
> > tricks.
> 
> It needs to be compressed, which is why the truncation didn't really 
> matter.  The reason it needs to be compressed, is because it can't live 
> in the squashfs, it has to live on the iso9660.  And note, that it 
> compresses from 1.2M of actual data, to 7kb of actual data.

	It can be truncated down to 1.2M, but it can still be compressed to
7kb? If so, the compression does sounds worthwhile.

> Honestly I thought that using the exact same mechanism to propogate 
> osmin.img as was used to propogate os.img, was not a trick, but elegant.

	What you have is mostly fine IMHO, it was the tarball I had a problem
with.

Cheers,
Mark.




More information about the livecd mailing list