Bug 803108 - Block devices are not created for 17th(or higher) partition of a device mapper volume
Summary: Block devices are not created for 17th(or higher) partition of a device mappe...
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: parted
Version: 6.2
Hardware: x86_64
OS: Linux
Target Milestone: rc
: 6.3
Assignee: Brian Lane
QA Contact: Release Test Team
Depends On:
Blocks: 740303 840685
TreeView+ depends on / blocked
Reported: 2012-03-14 01:29 UTC by Jason Varkey Cheruvatoor
Modified: 2013-02-21 10:13 UTC (History)
15 users (show)

Fixed In Version: parted-2.1-19.el6
Doc Type: Bug Fix
Doc Text:
Cause: Only the first 16 partitions on a dm device were re-synchronized. Consequence: partitions greater than 16 would not show up until a reboot. Fix: re-synchronize all of the partitions. Result: new partitions appear without a reboot.
Clone Of:
Last Closed: 2013-02-21 10:13:34 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0407 0 normal SHIPPED_LIVE parted bug fix and enhancement update 2013-02-20 20:50:39 UTC

Description Jason Varkey Cheruvatoor 2012-03-14 01:29:08 UTC
Description of problem:
Block devices are not created for 17th(or higher) partition of a device mapper volume. The block devices appear when the mpath volumes are flushed and recreated, but disappear again if partitions are added/deleted.

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

How reproducible:
Reproducible every time

Steps to Reproduce:
1. Present LUNs from SAN, configure mpath volume.
2. Using parted create GPT label on the mpath device (/dev/mapper/mpathx device)
3. Create 16 partitions on the device - ensure that /dev/mapper/mpathxpN block devices are created
4. Create 17th partition - the /dev/mapper/mpathxpN devices are not created for any partitions more than 16.
5. The partitions are actually created and can be seen with the parted tool.

Note - 
1. The partitions are seen if the device mapper mpath volume is flushed and rescanned(multipath -f /dev/mapper/mpatha and multipath -v2).
2. Block devices belonging to partitions greater than 16(e.g. mpathap17) is removed if a new partition is created or deleted.  
3. This behavior is seen only on mpath devices and not seen on /dev/sd* devices.
4. This behavior was observed when trying to partition the disk using virt-manager. Partition creation fails on partitions greater than 16.

Actual results:
Block devices are not created for 17th(or higher) partition of a device mapper volume

Expected results:
Block devices should be created for 17th(or higher) partition of a device mapper volume up to 128 partitions for a disk with GPT label.

Additional info:

Comment 2 Ben Marzinski 2012-03-20 02:38:23 UTC
I can recreate this. I'm not exactly sure what's going wrong, but there are no udev events for any device past the 16th when you run mkpart with parted.  The reason it does work when you do things to the multipath device is that when the multipath device sends a udev event, the multipath udev rules will make sure the partitions are there.

An easier way to make the device appear is to simply run

# multipath -r [devname]

This will force a reload of the multipath device, which fires off a change udev event and creates the missing partition.

Comment 3 Ben Marzinski 2012-03-20 04:07:57 UTC
When I run a strace on the parted command, I don't see it even trying to create a 17th partition device, despite the fact that it did write out the partition to disk.

Looking through the parted code, in _dm_reread_part_table(), I see

        int     last = PED_MIN (largest_partnum, 16);

This looks like the root of the problem. reassigning to parted.

Comment 4 Brian Lane 2012-03-21 20:33:34 UTC
What version of parted are you using?

Comment 5 Brian Lane 2012-03-21 23:37:01 UTC
Looks like the change discussed in this thread - http://thread.gmane.org/gmane.comp.gnu.parted.devel/2213 should not have applied to _dm_reread_part_table

Here is a scratch-build that reverts that change, using PED_MAX instead. https://brewweb.devel.redhat.com/taskinfo?taskID=4178996

I've successfully reproduced it on a dm setup on top of a disk image and that fixes the problem.

Comment 7 Brian Lane 2012-07-12 17:47:31 UTC
Making this bug public so others can contribute.

Comment 10 RHEL Program Management 2012-07-16 22:48:42 UTC
This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release.  Product
Management has requested further review of this request by
Red Hat Engineering, for potential inclusion in a Red Hat
Enterprise Linux release for currently deployed products.
This request is not yet committed for inclusion in a release.

Comment 13 Jan Stodola 2013-01-03 12:35:57 UTC
Reproduced with parted-2.1-18.el6, verified with parted-2.1-19.el6:

[root@rtt7 ~]# for i in `seq 1 128`; do start=$((i*20)); end=$((start+19)); parted /dev/mapper/mpatha mkpart primary $start $end; done
[root@rtt7 ~]# ls /dev/mapper/
control     mpathap11   mpathap122  mpathap2   mpathap32  mpathap45  mpathap58  mpathap70  mpathap83  mpathap96
mpatha      mpathap110  mpathap123  mpathap20  mpathap33  mpathap46  mpathap59  mpathap71  mpathap84  mpathap97
mpathap1    mpathap111  mpathap124  mpathap21  mpathap34  mpathap47  mpathap6   mpathap72  mpathap85  mpathap98
mpathap10   mpathap112  mpathap125  mpathap22  mpathap35  mpathap48  mpathap60  mpathap73  mpathap86  mpathap99
mpathap100  mpathap113  mpathap126  mpathap23  mpathap36  mpathap49  mpathap61  mpathap74  mpathap87  vg_rtt7-LogVol00
mpathap101  mpathap114  mpathap127  mpathap24  mpathap37  mpathap5   mpathap62  mpathap75  mpathap88  vg_rtt7-LogVol01
mpathap102  mpathap115  mpathap128  mpathap25  mpathap38  mpathap50  mpathap63  mpathap76  mpathap89  vg_rtt7-LogVol02
mpathap103  mpathap116  mpathap13   mpathap26  mpathap39  mpathap51  mpathap64  mpathap77  mpathap9
mpathap104  mpathap117  mpathap14   mpathap27  mpathap4   mpathap52  mpathap65  mpathap78  mpathap90
mpathap105  mpathap118  mpathap15   mpathap28  mpathap40  mpathap53  mpathap66  mpathap79  mpathap91
mpathap106  mpathap119  mpathap16   mpathap29  mpathap41  mpathap54  mpathap67  mpathap8   mpathap92
mpathap107  mpathap12   mpathap17   mpathap3   mpathap42  mpathap55  mpathap68  mpathap80  mpathap93
mpathap108  mpathap120  mpathap18   mpathap30  mpathap43  mpathap56  mpathap69  mpathap81  mpathap94
mpathap109  mpathap121  mpathap19   mpathap31  mpathap44  mpathap57  mpathap7   mpathap82  mpathap95
[root@rtt7 ~]#

Moving to VERIFIED.

Comment 15 errata-xmlrpc 2013-02-21 10:13:34 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.