Bug 248082 - anaconda liveinst livecd installer is inefficient and doesn't support barely large enough destination volumes
anaconda liveinst livecd installer is inefficient and doesn't support barely ...
Product: Fedora
Classification: Fedora
Component: LiveCD (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: David Zeuthen
Depends On:
  Show dependency treegraph
Reported: 2007-07-12 23:49 EDT by Jane Dogalt
Modified: 2013-03-05 22:51 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-16 16:00:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jane Dogalt 2007-07-12 23:49:42 EDT
Description of problem:

Maybe this is 2 seperate bugs.  Either way I'm working on a fix right now.

Currently anaconda does effectively a 
dd if=os.img of=/dev/destvol 
resize2fs /dev/destvol

Since os.img is a 4G sparse file housing 2.2G of data, this results in two
problematic things-

1) 1.8G of zeros are written to the destvol that needn't be
2) destination volumes of size 2.3G->3.9G are unsupported when they could be.

I have a solution involving devicemapper snapshots and resize2fs that I believe
will be good for the long term.

Originally I had wondered if this might be causing the livecd installer to take
upwards of ~75% longer than it needs to to perform the install.

Simulated tests on a modern laptop (vaio vgn-n250) shows that an install from CD 
the detriment might be around 12%, while an install from usbstick that supports
reading at 8.5MB/s, causes a detrimental effect of perhaps 35%.

The simulated test was a dd from a 2.5G squashed image, versus the same image in
a 4.0G squashed container (and about 2.2G of data in the fs itself).

I.e. the slow read speed on the cdrom, and perhaps the squashfs decompression
time, mask the ~75% extra data written to disk to varying degrees.

But as faster cpus and faster flash become available, this will be a more
serious problem...  which I think I can solve gracefully here in a day or two.

An alternate solution that markmc proposed, involved implementing copy support
(e.g. functionality like his e2cp program) in resize2fs.  As it happens I think
that the devicemapper tricks I'll use to try and solve this will inadvertantly
have the side effect of implementing that (without any knowledge of ext2
internals :)  Though I don't know yet if the devicemapper layer I plan on using
will impose an acceptable or unacceptable penalty of its own.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Jane Dogalt 2007-07-16 01:00:17 EDT
I haven't quite got around to fixing this.  I got distracted and had to fix that
redundant rootfs format bug first.  Since I went to the trouble of collecting
this data, which is also relevant for that bug as well, I'll go ahead and post
it here.

I performed 5 installs onto my vaio vgn-n250 laptop (core duo, sata laptop drive
(hdparm -t == 40 MB/s).  The flash used was 8.5MB/s.  cdrom used is 1.6MB/s.

3 live isos were used.  stock f7, replicated f7 (with livecd tools), and
replicated f7 with a 2.5G container instead of the default 4.0G container. 
about 2075MB of data within the filesystem.

each test was also performed after doing livecd-iso-to-usb. (thus the 6(-1) tests).

I measured the time the user waits for the install, this being 3 phases-

1) format rootfs
2) copy live image to drive
3) postinst stuff

I did not do a stock-f7 usb test, as mainly I used the stock-f7 cd test to
verify that my respun numbers were not off base.  30G rootfs was used in all tests.


format   41s
copy     99s
postinst 75s


format   41s 
copy    131s
postinst 75s


format   49s
copy    262s
postinst 89s


format   49s
copy    290s
postinst 89s


format   47s
copy    291s
postinst 89s


copy benefit interpolated up by ~25% to factor for optimal case, i.e.
4.0G->2.1G, rather than 4.0G->2.5G

for flash case, overall

89+75=164 vs 41+131+75=247, 
83/164= "F7 took 50% longer to install than it could have"
41s saved from format, 42s saved from copy

for cdrom

253+89= 342 vs 49+290+89=428, 
86/342= "F7 took 25% longer to install than it could have"
49s saved from format, 37s saved from copy
Comment 2 Jane Dogalt 2007-07-16 01:36:37 EDT
I mentioned on the fedora-livecd-list to markmc that my solution involving
on-the-fly resize2fs-ing down to minimal isn't going to work.  Not only is there
the issue of ram usage, the fatal flaw with that theory is that the
resize2fs-minimization process will likely(??) require lots of reads hitting the
install media(e.g. cdrom), which I suspect will be atrocious.

The final (I say a bit prematurely) solution then hit me-

During livecd-creator compose time

1) after done composing the 4.0G os.img as happens now, do a resize2fs down to
minimal, truncate the file to minimal, resparsify it back to 4.0G.

This step by itself, while time consuming (make it a flag to livecd-creator if
this is an issue), is useful in that it will remove any data taken up by files
that were written during the install and then deleted for some reason (I'm
guessing there are at least a few).

2) now, still during livecd-creator compose, snapshot the image, overlay file on
disk, and run a resize2fs minimize pass.  Then (here is the magic) include that
snapshot file (which by all rights should be very small, if not, a pretty bad
bug with resize2fs) on the cdrom alongside os.img.

3) now, during anaconda liveinst time, recreate the snapshot device, thus you
have access to a minimal os.img for use in copying efficiently to drive.  If for
some reason having that overlay file on cdrom slows things down, read it into
/dev/shm(tmpfs) first.

This design does hinge on the overlay file being small, and the snapshot device
not imposing a serious penalty.  But my fairly strong hunch is that that will be
the case.
Comment 3 Jane Dogalt 2007-07-16 01:40:33 EDT
oops, forgot in step 1, after resparsifying back to 4.0G, resize2fs back to 4.0G
as well.
Comment 4 Jeremy Katz 2007-07-16 16:00:10 EDT
I have to wonder a bit if this is getting to the point of over-optimization --
the cost of doing all of the resizing + snapshotting is going to be pretty
large.  And being able to build live CD fast is going to be increasingly
important.  For cases where you really care about making this level of
optimization, we already let you specify the size of the rootfs image and so
that's going to likely be the better approach.
Comment 5 Jane Dogalt 2007-07-16 17:03:08 EDT
I disagree.  I think the time measurements show the benefits.

All the resizing + snapshotting happens at livecd creator time, which can be a
flag, so that it needs only be done for mass shipping spins.

The snapshot does get _used_ at install time, but I suspect it won't be that bad.

Anyway, I may still produce a patch and do some tests, and post.

Just setting the size at creation time, isn't an answer I think.  I think you
need the +2G space, such that livecd users with 2G of ram are allowed to utilize
it.  Actually, the issues with that are also related to issues with the
currently undefined persistence livecd wishlist feature.  I.e. do we support
persistance to an 8GB usbstick?  If so, how does that get implemented?

(though that discussion is I think for fedora-livecd-list, and not this bug)

Comment 6 Jane Dogalt 2007-07-20 04:07:53 EDT
Douglas McClendon :) posted a patch that takes care of much of this, as well as
reclaiming 5.5% wasted space on the F7-i686-LiveCD.  Please review that patch
ASAP.  If it looks like it will get applied more or less as is, I'll go forward
implementing the rest of the above, hopefully in time for the F8T1 devel freeze.

I can implement in such a way that it is easily verifiable that by default,
nothing will happen differently, either with the boot sequence, or anaconda.  If
however a boot arg is given (e.g. by f8t1 testers actively testing this
feature/bugfix), then a dm-linear layer will be inserted on top of the os.img
loop device (so it can be simultaneously used as part of the live-rw-rootfs, and
as part of the minimized-installable-rootfs), and anaconda will take advantage
of it, and the <<1MB extra minimized-fs-overlay file provided by livecd-creator
will be utilized.
Comment 7 Jane Dogalt 2007-07-21 02:32:16 EDT
As always, a little more mind-bending thought with devicemapper, and I realize
that no bootarg or futzing with the existing boot sequence will be needed.

I had been happy to discover that dm allows you to use a single device to create
multiple mountable devices.  (i.e. that rebootless theoretical workaround #5...).

But what I just realized, is that because the loop device associated with
os.img, is _already_ a component of devicemapper in the livecd scenario (i.e. a
part of the snapshotted /dev/mapper/live-rw), that it can be reused to build the
minimized image at runtime (without any extra stuff happening during early boot)

Note You need to log in before you can comment on or make changes to this bug.