Red Hat Bugzilla – Bug 352481
excessive seeks during "Starting install process."
Last modified: 2008-06-21 12:57:54 EDT
Description of problem: When installing from DVD or CDs, then there is excessive
seeking (constantly for half a minute or more) at the point when the information
box "Starting install process. This may take several minutes..." appears.
Seeks are very slow (only 6 to 9 per second on most drives) and should be
avoided in order to speed up the process and reduce wear on the drive.
Version-Release number of selected component (if applicable):
How reproducible: always
Steps to Reproduce:
1. fresh install from DVD or CD
Actual results: Much seeking (listen to the drive) at "Starting install process."
Expected results: Little seeking
Additional info: Running strace on the anaconda process (put strace on a usb
flash drive, have it plugged in when booting, use shell on vtty2 to mount the
usb flash drive) shows many accesses to the Packages directory on the media.
See if reading the whole directory beforehand (such as "dd if=Packages
of=/dev/null bs=2k") will cache the directory using the minimum number of seeks,
which is likely to be nfiles/40 or so. Perhaps there are other files which
would benefit from such caching, also.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Does this problem persist with Fedora 9?
Yes, the excessive seeks at "Starting install process" when installing from DVD
still occur in Fedora 9.
There are two causes. The first one is that the Packages/*.rpm are ordered
alphabetically on the platter, instead of in install order (generally: sorted
topologically by dependencies). The "-m" parameter to mkisofs should be able to
re-order the *.rpm on the platter. If the *.rpm are on the platter in install
order, then the seeks at "Starting install process" should always be towards
higher-numbered sectors, which would tend to make them shorter and thus faster.
The second cause is that only the RPM_Header records are read, skipping the rest
of the .rpm file. In theory this can be fixed, too, because the .iso file
format allows the file to be split into discontiguous spans of sectors. The
optimal would be to split each *.rpm at the first 2KB sector boundary after the
RPM_Headers, then place all the header spans consecutively (in topological order
by dependencies), then place all the non-header spans (again in topological
order.) The cost for discontigous spans is: the directory grows because it has
one entry for each span. mkisofs must create such a layout, and the ISO-9660
filesystem driver in the Linux kernel must understand it.
We're honestly not going to get around to implementing this on our own. There's
simply too many other higher priority issues to deal with right now and not
nearly enough time to investigate. However, I'll review any patches that come up.