Bug 589117

Summary: [RHEL-5] parted takes longer to create large number of partitions on 5.5 than on 4.8
Product: Red Hat Enterprise Linux 5 Reporter: michal novacek <mnovacek>
Component: partedAssignee: Brian Lane <bcl>
Status: CLOSED WONTFIX QA Contact: Release Test Team <release-test-team-automation>
Severity: medium Docs Contact:
Priority: low    
Version: 5.5CC: hdegoede, meyering, rmusil
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 590540 (view as bug list) Environment:
Last Closed: 2011-07-27 18:24:07 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:
Bug Depends On:    
Bug Blocks: 590540    
Attachments:
Description Flags
Shows problem described. none

Description michal novacek 2010-05-05 12:38:38 UTC
Created attachment 411579 [details]
Shows problem described.

Description of problem: 
Creating bigger number of partition than usual (66) on rhel5.5 lasts longer than on rhel4.8. I observed this behaviour when I tried to create about 40 partitions on iscsi disks but it is also easily reproducible on loop device only the time difference is smaller.

Version-Release number of selected component (if applicable):
5.5 
kernel: 2.6.18-194.el5
parted-1.6.19-23.EL.1

4.8:
parted-1.6.19-23.EL.1.i386
kernel: 2.6.9-89.0.23.ELsmp

How reproducible: always

Steps to Reproduce:
time run attached parted.test.sh and compare time on 4.8 and 5.5 
  
Actual results: takes longer on rhel5.

Expected results: takes less or equal on rhel5.

Additional info:
I used dell-pem905-01.rhts.eng.bos.redhat.com, did fresh install of 4.8 and run
the script attached and repeated for 5.5 fresh install on the same
machine. For iscsi I used software initiator on
gs-bl460cg1-01.rhts.eng.bos.redhat.com with loop device as underlying disk and
for each test I created fresh divce and target.

     iscsi    loop
5.5: 4min27s  38s
4.8: 45s      25s

That gives difference in time from 4.8 to 5.5 152% for loop device and almost 600% for iscsi device. 

Also, I started getting this message after each partition creation after creation of 12th partition (but that may be other problem):
Error: Error informing the kernel about modifications to partition /dev/sdd16
-- Invalid argument.  This means Linux won't know about any changes you made to
/dev/sdd16 until you reboot -- so you shouldn't mount it or use it in any way
before rebooting.

Comment 1 Jim Meyering 2010-05-06 12:59:03 UTC
Thanks for the report and test script.  Things have changed a lot in that area in upstream parted, and since I'm on the verge of releasing parted-2.3, it is worth ensuring that this works properly, so I added a new test:

http://git.debian.org/?p=parted/parted.git;a=commitdiff;h=246c953b53c1bd49b1f835f84a1ca29a6d2fbc1c

Running that new test on F13, its 60 partitions are created on a scsi_debug device in about 15 seconds.

Comment 3 Hans de Goede 2010-05-10 06:46:35 UTC
Michal, thanks for the reports.
Jim, thanks for testing!

I'm going to split this bug into 2 bugs, keeping this one to track the
slowdown. And adding a new one to track the failure in notifying the OS of any partitions with a partition nr > 15.

Comment 4 Hans de Goede 2010-08-13 08:14:09 UTC
Hi,

I've been taking a look at this today, and the following is happening:

1) RHEL-4 and RHEL-5 parted will only notify the kernel about the first 16 new partitions
2) But the blkpg ioctl used by parted to notify the kernel about new partitions only works for up to 15 partitions, so this fails at the 16th partition (this is the error msg seen / bug 590540)
3) When the notification of the 16th partition fails, RHEL-4 parted gives up, where as if cancel is chosen up on the error msg (*), RHEL-5 parted switches to using the BLKRRPART ioctl, including sleeping and retrying a couple of times. This will happen once per partition being added over number 16, which adds up to the large delay seen.

Regards,

Hans

*) Note that cancel is automatically chosen when running in script mode.