[Fedora-livecd-list] RFC- improving livecd installer efficiency

Douglas McClendon dmc.fedora at filteredperception.org
Tue Jul 10 14:01:25 UTC 2007


Douglas McClendon wrote:
> Douglas McClendon wrote:
>> Question:  Does the current livecd installer inefficiently write lots 
>> of 0's to the destination drive that it doesn't need to?
>>
>> I think it might.  The os.img on the F7 livecd is a 4G sparse file 
>> with about 2.3G of data.  Anaconda's livecdcopy backend uses python's 
>> os.read/write.  I would guess that that means that 4G of data is 
>> getting written, when theoretically only 2.3G needs to.
>>
>> The solution that comes to mind is this-
>>
>> in livecd-tools, create the os.img as a 7G (or 700G??) sparse file.  
>> Basically just way big.  Then take care to make the ext3fs be the 
>> exact correct size for the data (i.e. 2.3G).  Then, in the initramfs, 
>> just after mounting it (after snapshotting it), do a resize2fs to 7G 
>> (or 700G).
> 
> To clarify a bit- Clearly the resize2fs should probably happen during 
> boot (long after initramfs).  No need to bloat the initramfs with 
> resize2fs.


Assuming my prior logic is valid, there is another aspect to consider-

The above recommendation would add some time to every livecd boot sequence. 
However long resize2fs would take to run.  Also, whatever metadata resize2fs 
would write to the overlay, would be a permanent ram penalty (albeit small 
hopefully).

An alternate idea I had, is that you could build the minimized ext3fs image as 
described, but then resize2fs it back to the larger size - during spin 
composition.  Then, at livecd install time, (note people, we are now talking 
about the normal livecd installer, not my crazy rebootless stuff), you could 
create a _second_ snapshot of the big read only ext3fs image, and then 
minimize-resize2fs it, before starting the copy to destination volume.

This is much more complicated, but probably the better solution, as it takes the 
delay and ram hit out of every livecd boot, and adds it only at install time 
(and the ram hit gets freed after installation completes).  The livecd build 
time resize2fs minimization(and remaximization) might still be a good idea, if 
it helps minimize the ram and processing time required to do the anaconda 
install time minimize-resize2fs.

-dmc


> 
> Also, the mechanism that comes to mind for the ext3fs creation is this-
> 
> Take the existing image built as is, but after final install, resize2fs 
> it to the smallest possible (nearly), then truncate the file, then do 
> the dd seek trick to re-sparsify it vastly larger.
> 
> Or perhaps just throw in an entire extra tarcopy of the system to a new 
> fs image file created the exact right size from the beginning.  This is 
> more work, but will possibly save space on any files that got created 
> and deleted during the installation process.
> 
> -dmc
> 
> -- 
> Fedora-livecd-list mailing list
> Fedora-livecd-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-livecd-list




More information about the livecd mailing list