Bug 485594 - rescue mode takes three minutes to identify 30 partitions
rescue mode takes three minutes to identify 30 partitions
Product: Fedora
Classification: Fedora
Component: pyparted (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-02-14 20:17 EST by John Reiser
Modified: 2009-03-31 14:58 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-03-31 14:58:46 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 John Reiser 2009-02-14 20:17:55 EST
Description of problem: Booting rescue mode takes three minutes of cpu time to construct the list of partitions to rescue, and another three minutes to mount the selected partition as /mnt/sysimage.  The box has 3 SATA disks with (6 + 9 + 15) partitions; two "basic" (DOS) partition tables, one GPT (GUID Partition Table), no LVM at all (Linux Volume Manager version 1 or 2).

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

How reproducible: always

Steps to Reproduce:
1. boot rescue mode of boot.iso netinst CD-ROM
2. Select default language, keyboard, etc.
Actual results: Gettting to the dialog box to select the system to rescue (the root partition, which requires identifying all the eligible partitions) takes three minutes.  Mounting that partition as /mnt/sysimage takes an additional three minutes.  The hardware activity light for the disk controller is ON almost all the time during those six minutes, and the rescue CD-ROM is not spinning at all.

Expected results: The budget should be no more than 1 second per partition (that's 100 seeks [one hundred]).

Additional info:  Timing was by "ps ax" on alternate screen (Ctrl-Alt-F2) and verified by external wristwatch.
Comment 1 Chris Lumens 2009-02-16 11:34:06 EST
Yeah, it's pretty slow for me today too.  We definitely intend to look into the speed problems with the new pyparted, but we first wanted to make sure it was correct.
Comment 2 Chris Lumens 2009-02-25 17:45:08 EST
We've made some improvements both in avoiding unnecessary type conversions and in caching results, so the next build of anaconda and pyparted should show a decent amount of improvement.  Please test the next build (which should be within the next couple of days) and let me know if it's acceptable for you, or if it's still unreasonably slow.  If it's still slow, we're going to have to dive in more deeply to get it straightened out.
Comment 3 John Reiser 2009-03-05 23:53:19 EST
Today's boot.iso rescue mode (Thursday, 2009-03-05) is broken even worse.  It says, "You don't have any Linux partitions."  Nevertheless, running fdisk and parted from the shell can find all (6+9+15) of the partitions.  Only one is NTFS with Vista.  All others are ext3 or swap, with at least 8 Fedora root partitions, all the way from FC6 through F11alpha.  This happens on both i386 and x86_64.  Anaconda announces itself as version
Comment 4 Chris Lumens 2009-03-06 10:08:25 EST
We've merged all the rest of the storage code into rawhide, which is probably what you are seeing.  It's worth filing a new bug against anaconda for that as it's likely got nothing to do with pyparted.
Comment 5 David Cantrell 2009-03-27 16:55:57 EDT
Please test the Fedora 11 Beta release when it becomes available to see if this problem is still happening for you.
Comment 6 John Reiser 2009-03-31 14:58:46 EDT
Rescue mode of Fedora-11-Beta-i386-DVD.iso detects the 30 partitions in about 12 seconds.  anaconda-

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