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: | parted | Assignee: | Brian Lane <bcl> | ||||
Status: | CLOSED WONTFIX | QA Contact: | Release Test Team <release-test-team-automation> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 5.5 | CC: | 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: |
|
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. 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. 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. |
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.