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):
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.
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.
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
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:
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.
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.
*) Note that cancel is automatically chosen when running in script mode.