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): anaconda-11.3.0.45 How reproducible: always Steps to Reproduce: 1. fresh install from DVD or CD 2. 3. 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.