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

Douglas McClendon dmc.fedora at filteredperception.org
Tue Sep 4 21:47:10 UTC 2007


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

[snip]

thanks for providing the dumpe2fs python code Mark and Collin, should 
save you a cleanup patch later on :)

[snip]

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

Yup.  I can't actually wrap my head around the 1.2M->7kb compression, 
but I can give a reasonable explanation about why the inverse is 
possible.  By the inverse, I mean using a snapshot to create a delta 
describing the differences between the minimized-fs and the maximized-fs 
(not max->min as is the actual case in use).  I.e. in the min->max, all 
that is happening is some repetitive formatting of the filesystem out in 
the new unused area.  As a result all that repetitive stuff can compress 
down to next to nothing.  I assume something similar is happening in the 
max->min case.

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

Ok, in that case, it should be no sweat (relatively) to put together a 
new version of the patch, updated against the 30+ commits seen since the 
last version, which uses dumpe2fs in anaconda, no tarball, osmin.img 
truncation, and setting loops and dms to readonly where possible.

But, before I do that, can I get feedback from one other person, 
preferably who has commit authority, to tell me that this will be 
committed?  Jeremy, you mentioned objections in the past?  (all my 
goading of said objections, was because I was so sure that there is no 
remotely more correct way to accomplish the task, and I would be 
genuinely entertained to be corrected on that fact)

I would also like to grumblingly say, that I think it would have been 
much better if this review could have been done sooner, so that it could 
make it into F8T2.  This seems like a significant improvement (20% 
install speedup), which could have easily been in F8T2, and thus out of 
the way as a cloud of potential problem hanging over F8T3.

-dmc


> Cheers,
> Mark.
> 
> --
> Fedora-livecd-list mailing list
> Fedora-livecd-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-livecd-list




More information about the Fedora-livecd-list mailing list