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?
[EMC RHEL 6.1 FEAT] kernel dm: Should the creation of a new block device part...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: device-mapper (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: 6.2
Assigned To: LVM and device-mapper development team
Cluster QE
: FutureFeature, OtherQA
Depends On:
Blocks: 659725 662543
  Show dependency treegraph
 
Reported: 2005-05-02 10:12 EDT by Ed Goggin
Modified: 2011-06-28 12:40 EDT (History)
29 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-28 12:40:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ed Goggin 2005-05-02 10:12:41 EDT
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 14:36:22 EDT
Alisdair - do you have any feedback on Ed's request?
Thanks.
Heather
Comment 2 Heather Conway 2005-09-15 11:33:46 EDT
Alisdair - do you have any feedback on Ed's request?
Thanks.
Heather
Comment 9 Heather Conway 2006-01-16 11:44:56 EST
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 11:06:56 EST
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 11:27:46 EDT
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 10:01:33 EST
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 11:24:36 EDT
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-05 22:52:15 EST
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 18:16:08 EST
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 11:05:06 EST
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 09:29:32 EST
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 11:01:23 EST
We didn't expect this to be a trivial change. =;^)
Comment 36 RHEL Product and Program Management 2011-01-06 22:54:31 EST
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 10:33:02 EST
(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 Yeghiayan 2011-01-07 11:17:39 EST
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 15:41:55 EST
Ben, Mike, Peter - what is the current situation?  What more should we do?
Comment 41 Mike Snitzer 2011-02-11 16:45:09 EST
(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-13 22:26:26 EST
(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 06:35:42 EST
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 10:05:13 EST
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.