[Fedora-livecd-list] [PATCH] cleanupDeleted and container_size - saves 5.5% output size on f7livecd-i686

[Douglas McClendon]

Douglas McClendon wrote:
> Attached is a patch.
>  

...

> Please review.  Any comments, suggestions, or criticisms are welcome.  I 
> still consider myself a relative novice when it comes to python.


Just a heads up, I noticed one minor bug, in that the e2fsck invoked by the 
patch will fail if you have redirected the output of livecd-creator.  Thus a -y 
(or -p?) needs to be added to that call.

Since I have done more testing, and figured out that I can implement the 
'turboinstaller' without even impacting mayflower, I'll probably post a new 
version of the patch this weekend sometime.  Amongst my thoughts are

a) is there really any reason to not make the container-size be 1T by default, 
and not even have the option?  I guess I'll leave it as is for now, but suggest 
that f8t1 ship with 1T if nobody can suggest any reason not to.  Likewise for 
the overlay which is currently 512M.

b) the cp --sparse is a fairly time consuming step for very little return, so it 
seems like it might best be housed by a --resparse flag.

c) the ugly heuristic for determining minimal resize amount, can be replaced by 
one which starts at 110% of calculated data size, and then homes in the target 
and even optomized down the smallest 4K amount.  Thus I suspect it can be 
reduced from a process that takes a couple minutes, down to one which takes a 
couple seconds.

d) given (b) and (c), and given that the benefits of cleanup-deleted are so 
immense (5.5% on stock f7i686-livecd, 20+% on Patrice Guay's use case), I think 
it should happen by default.

e) I'll add a --turbo-liveinst flag (see bug 248082), which will cause a 
generation of the minimized overlay to sit alongside os.img, and then I'll 
create a patch to anaconda which just checks to see if it exists, and uses it if 
it does.  I've run some tests, and the penalty appears to be about half a meg 
for the overlay file, and while I can't nail down the overhead for the 
devicemapper layer, it seems to be rather small, which means that the mechanism 
should provide a significant (? 5%-50% ?) benefit for installation speed, as 
well as removing the artificial limitation on installation volume size.  (or 
maybe I'm wrong, we'll see...)

peace...

-dmc