Bug 485594

Summary:	rescue mode takes three minutes to identify 30 partitions
Product:	[Fedora] Fedora	Reporter:	John Reiser <jreiser>
Component:	pyparted	Assignee:	David Cantrell <dcantrell>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	rawhide	CC:	dcantrell
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-03-31 18:58:46 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description John Reiser 2009-02-15 01:17:55 UTC

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):
anaconda-11.5.0.19

How reproducible: always


Steps to Reproduce:
1. boot rescue mode of boot.iso netinst CD-ROM
2. Select default language, keyboard, etc.
3.
  
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 16:34:06 UTC

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 22:45:08 UTC

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-06 04:53:19 UTC

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 11.5.0.24.

Comment 4 Chris Lumens 2009-03-06 15:08:25 UTC

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 20:55:57 UTC

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 18:58:46 UTC

Rescue mode of Fedora-11-Beta-i386-DVD.iso detects the 30 partitions in about 12 seconds.  anaconda-11.5.0.38.