Alisdair - do you have any feedback on Ed's request?
Thanks.
Heather

Alisdair - do you have any feedback on Ed's request?
Thanks.
Heather

Hi Alasdair - have you had an opportunity to review Ed's request?  If so, would 
you please provide an update?
Thanks.
Heather

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.

No direct progress, though more workarounds are appearing. (such as clvmd
reload; better udev/lvm2 integration firmly on the agenda)

Alasdair, checking on this, as this is on the list for RHEL 5.1... Any progress
since Comment #17?

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.

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...

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.

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.

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...

We didn't expect this to be a trivial change. =;^)

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.

(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.

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.

Ben, Mike, Peter - what is the current situation?  What more should we do?

(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?

(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

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?

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.