I see someone besides me uses mailing lists to keep public notes for
themselves to remember later. :)
On Tue, 10 Jul 2007, Douglas McClendon wrote:
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.
Yeah, I really gotta stop posting when I'm sleep deprived. Clearly in
initramfs you have access to sysroot thus no bloat.
> 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.
clearly the resize2fs to minimal will take care of the created/deleted issue.
Fedora-livecd-list mailing list
Community Development Manager
Red Hat, Inc. :: 1-919-754-4255
"To whomsoever much hath been given...
...from him much shall be asked"