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
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
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.
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.
Fedora-livecd-list mailing list