Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 820473

Summary: RUNNING PARTED IN PARALLEL ON DIFFERENT DISKS MAY FAIL UNDER LOAD
Product: Red Hat Enterprise Linux 6 Reporter: Luan Jianhai <jianhai.luan>
Component: partedAssignee: Brian Lane <bcl>
Status: CLOSED WONTFIX QA Contact: Release Test Team <release-test-team-automation>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.2CC: saar.maoz
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-05-11 23:44:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch for fixe the bug. none

Description Luan Jianhai 2012-05-10 05:40:25 UTC
Description of problem:
  When run parted on multiple disks in parallel under medium IO load, the below warning message will be show.
  Warning: WARNING: the kernel failed to re-read the partition table on /dev/sdc (Device or Resource Busy). As a result, it may not reflect all of your change until after reboot.

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

How reproducible:


Steps to Reproduce:
1. Prepared 4 disks.
2. run the below test.sh

PARTED=/sbin/parted
while [ 1 ]; do
  for d in c d e f: do 
    disk=/dev/sd${d}
    $PARTED $disk --script --mklabel msdos mkpart primary 2048s -1s &
  done
  wait  
done

3. After running for several short minutes, the warning information will be show.
  
Actual results:
  the below warning formation show.
  Warning: WARNING: the kernel failed to re-read the partition table on 
  /dev/sdc (Device or resource busy).  As a result, it may not reflect all of 
  your changes until after reboot.

Expected results:
  No Warning.

Additional info:

Comment 2 Luan Jianhai 2012-05-10 05:45:57 UTC
Created attachment 583438 [details]
patch for fixe the bug.

This patch effectively reverses commit 1d8f9bec which removed the code using the new BLKPG ioctls instead of the old BLKRRPART ioctl to update the in-kernel partition table.  The reason for this is because BLKRRPART fails if any partition on the disk is in use, but the BLKPG ioctls allow you to manipulate the other partitions on the disk without requiring a reboot.  Also BLKRRPART requires that the kernel understand the partition table on the disk, which may not always be the case.

Comment 3 Brian Lane 2012-05-10 16:13:44 UTC
We are not going to change the BLKRPART code at this point. The potential for disruption is too great.

Don't operate on disks with active partitions.

Comment 4 Saar 2012-05-11 21:47:20 UTC
First:

The parted is never running on *active* partitions, each parallel parted is operating on a different disk, and only one partition exists on any disk.  There is nothing else running at that time touching or reading from the disks.

There are servers with 300+ disks, and they need to be partitioned concurrently, however, that is not possible in RHEL6 (without reattempts on failures, etc.), same concurrent partitioning works just fine in all RH4/5 releases.

Second:

The original report included a "udevadm settle", since a "wait" alone may not be enough, here is how it looks:

PARTED=/sbin/parted
while [ 1 ]; do
  /sbin/udevadm settle
  for d in c d e f: do 
    disk=/dev/sd${d}
    $PARTED $disk --script --mklabel msdos mkpart primary 2048s -1s &
  done
  wait  
done

This too fails on RH6, whereas it can work for days on RH4/5 w/o failure.  

Another solution we found is to move the udevadm settle to inside the inner loop so it gets executed after each parted.  Sounds like parted one disk A is somehow affected by operation on a different disk B.

Comment 5 Brian Lane 2012-05-11 23:44:57 UTC
Still not going to make that big of a change at this point.