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 156609 - [EMC RHEL 6.1 FEAT] kernel dm: Should the creation of a new block device partition automatically lead to the creation of device-mapper mapped devices and udev managed device file name for this partition?
Summary: [EMC RHEL 6.1 FEAT] kernel dm: Should the creation of a new block device part...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: device-mapper
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: 6.2
Assignee: LVM and device-mapper development team
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks: 659725 662543
TreeView+ depends on / blocked
 
Reported: 2005-05-02 14:12 UTC by Ed Goggin
Modified: 2018-10-20 00:50 UTC (History)
29 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-28 16:40:11 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Ed Goggin 2005-05-02 14:12:41 UTC 
Description of problem:

Should the creation of a new block device partition automatically lead
to the creation of device-mapper mapped devices and udev managed device
file name for this partition?  Need hotplug event generated at some
point, (e.g., BLKRRPART ioctl), to do so.  Similar logic applies to
the deletion of an existing block device partition.  None of this is
currently happening with the current code base.

My initial concern was in managing attribute data, (e.g., partition table, 
device size, read-only state, ...), consistently amongst all of the target
devices and the mapped device for any mapped device.  Both Christophe and
Lars brought up the issues regarding automated management of device-mapper 
resources for block device partitions after one is either created or deleted.

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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Heather Conway 2005-08-30 18:36:22 UTC 
Alisdair - do you have any feedback on Ed's request?
Thanks.
Heather
Comment 2 Heather Conway 2005-09-15 15:33:46 UTC 
Alisdair - do you have any feedback on Ed's request?
Thanks.
Heather
Comment 9 Heather Conway 2006-01-16 16:44:56 UTC 
Hi Alasdair - have you had an opportunity to review Ed's request?  If so, would 
you please provide an update?
Thanks.
Heather
Comment 10 Alasdair Kergon 2006-03-15 16:06:56 UTC 
Not a high priority because it's only a problem at partitioning time so it's not
a frequent task and you're already performing a manual action and the workaround
is to do one more manual step, run kpartx.

Probably best to try to get agreement to change this upstream and let it trickle
down into RHEL5.
Comment 17 Alasdair Kergon 2006-10-10 15:27:46 UTC 
No direct progress, though more workarounds are appearing. (such as clvmd
reload; better udev/lvm2 integration firmly on the agenda)
Comment 18 Andrius Benokraitis 2007-02-13 15:01:33 UTC 
Alasdair, checking on this, as this is on the list for RHEL 5.1... Any progress
since Comment #17?
Comment 20 Andrius Benokraitis 2007-06-20 15:24:36 UTC 
This needs serious thought and work, and almost positive this won't make 5.1
unless magic happened upstream... Any comments Alasdair/Dave?

Moving to RHEL 5.2 - could be a RHEL 6 item actually, but will need some comments.
Comment 24 Andrius Benokraitis 2007-11-06 03:52:15 UTC 
Ed/Wayne, this has been around quite a while, and this should really be deferred
to RHEL 6 or closed altogether since Ed (the requester) has moved on to VMWare
land...
Comment 25 Wayne Berthiaume 2007-11-06 23:16:08 UTC 
Hi Andrius.

   This would be a ease of use issue. When a partition is created wouldn't it 
improve the TCE of the OS if the uevent would cause /dev/mapper to be populated 
with the partitions? Presently, there is the added step of using kpartx to 
create these entries. I don't see this as an urgent matter but one that would 
improve the total customer experience.

Regards,
Wayne.
Comment 26 Dave Wysochanski 2007-11-12 16:05:06 UTC 
I doubt a fix will be ready for 5.2.
Made a little progress on this.  The ioctl is failing below because for a dm
device (as with dm-mp) disk->minors == 1:
static int blkdev_reread_part(struct block_device *bdev)
{
        struct gendisk *disk = bdev->bd_disk;
        int res;

        if (disk->minors == 1 || bdev != bdev->bd_contains)
                return -EINVAL;

So perhaps the first step involves some sort of fix to the major / minor number
space when device mapper devices are used?  Need to research this but the minors
check is preventing the rest of the partitioning kernel code from running.  I'm
not sure what is possible at this point, if anything.
Comment 27 Andrius Benokraitis 2007-11-13 14:29:32 UTC 
Wayne, after review from devel, it looks like this will have to get deferred to
RHEL 6. I've made Comment #26 from Dave public, since this may help explain
what's going on a bit...
Comment 28 Wayne Berthiaume 2007-11-13 16:01:23 UTC 
We didn't expect this to be a trivial change. =;^)
Comment 36 RHEL Program Management 2011-01-07 03:54:31 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.
Comment 37 Andrius Benokraitis 2011-01-07 15:33:02 UTC 
(In reply to comment #36)
> This request was evaluated by Red Hat Product Management for
> inclusion in the current release of Red Hat Enterprise Linux.
> Because the affected component is not scheduled to be updated
> in the current release, Red Hat is unfortunately unable to
> address this request at this time. Red Hat invites you to
> ask your support representative to propose this request, if
> appropriate and relevant, in the next release of Red Hat
> Enterprise Linux. If you would like it considered as an
> exception in the current release, please ask your support
> representative.

Please disregard this, as it was in error.
Comment 38 Suzanne Logcher 2011-01-07 16:17:39 UTC 
This request was erroneously denied for the current release of Red Hat
Enterprise Linux.  The error has been fixed and this request has been
re-proposed for the current release.
Comment 40 Alasdair Kergon 2011-02-11 20:41:55 UTC 
Ben, Mike, Peter - what is the current situation?  What more should we do?
Comment 41 Mike Snitzer 2011-02-11 21:45:09 UTC 
(In reply to comment #40)
> Ben, Mike, Peter - what is the current situation?

Depends on when the user partitions one of the underlying paths in relation to starting multipathd.

But say the mpath device was already created (multipathd running).  And the user wants to add parititons.

# multipath -ll
mpathb (360a98000486e584c5334556e3366644b) dm-0 NETAPP,LUN
size=10G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='round-robin 0' prio=50 status=active
| `- 2:0:0:0 sda 8:0  active ready running
|-+- policy='round-robin 0' prio=50 status=enabled
| `- 3:0:0:0 sdc 8:32 active ready running
|-+- policy='round-robin 0' prio=50 status=enabled
| `- 4:0:0:0 sdb 8:16 active ready running
`-+- policy='round-robin 0' prio=50 status=enabled
  `- 5:0:0:0 sdd 8:48 active ready running

# dmsetup table
mpathb: 0 20971520 multipath 1 queue_if_no_path 1 alua 4 1 round-robin 0 1 1 8:0 1000 round-robin 0 1 1 8:32 1000 round-robin 0 1 1 8:16 1000 round-robin 0 1 1 8:48 1000 

# fdisk /dev/sda
<create 2 partitions>

# kpartx -l /dev/mapper/mpathb 
mpathb1 : 0 2050016 /dev/mapper/mpathb 32
mpathb2 : 0 18921472 /dev/mapper/mpathb 2050048

# kpartx -a /dev/mapper/mpathb

# dmsetup table
mpathb: 0 20971520 multipath 1 queue_if_no_path 1 alua 4 1 round-robin 0 1 1 8:0 1000 round-robin 0 1 1 8:32 1000 round-robin 0 1 1 8:16 1000 round-robin 0 1 1 8:48 1000 
mpathb2: 0 18921472 linear 252:0 2050048
mpathb1: 0 2050016 linear 252:0 32

If the user partitioned the device before multipathd was running then kpartx would get invoked to map the partitions when multipathd is started.


> What more should we do?

who _really_ benefits from avoiding the extra 'kpartx -a' command?

if it is just the user who manually invoked the partition tool I'm inclined to say WONTFIX.

But maybe Ben or Peter have other ideas?
Comment 42 Mike Snitzer 2011-02-14 03:26:26 UTC 
(In reply to comment #41)
> (In reply to comment #40)
> > Ben, Mike, Peter - what is the current situation?
> 
> Depends on when the user partitions one of the underlying paths in relation to
> starting multipathd.
...
> If the user partitioned the device before multipathd was running then kpartx
> would get invoked to map the partitions when multipathd is started.

And to be clear, 'kpartx -a' is invoked by the udev rule provided by the device-mapper-multipath package:
/lib/udev/rules.d/40-multipath.rules
Comment 43 Peter Rajnoha 2011-02-14 11:35:42 UTC 
I think Milan already prepared the kernel patch to generate the uevents even when a DM device is partitioned. But it's not in upstream kernel yet... We also discussed the patch briefly with Kay and he was OK with it. Though there's one thing worth mentioning - such events won't be synchronized. The synchronization would need to be added to partitioning tools (to avoid "still opened" situation when kpartx would be called from within udev rules to process this event).

We can propose the patch, but as Mike says, who will benefit from this actually?
Comment 48 Ronald Pacheco 2011-02-17 15:05:13 UTC 
Ed,

We're not going to have sufficient time in RHEL 6.1 to fully address this issue, so we moved this to RHEL 6.2.
Note You need to log in before you can comment on or make changes to this bug.