Bug 448919 - fdisk -l shows wrong partition name on device-mapper-multipath devices
fdisk -l shows wrong partition name on device-mapper-multipath devices
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: util-linux (Show other bugs)
All Linux
low Severity low
: rc
: ---
Assigned To: Karel Zak
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2008-05-29 10:19 EDT by Joe Sunday
Modified: 2015-11-05 03:56 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-01-13 18:43:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 21730 None None None Never

  None (edit)
Description Joe Sunday 2008-05-29 10:19:47 EDT
Description of problem:
fdisk -l shows the RHEL 4 naming convention for device-mapper-multipath devices, not the RHEL 5
convention. Since the device shown is not the actual device, this could lead to confusion.

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

How reproducible:

Steps to Reproduce:
1. Create/Connect a multipathed disk using device-mapper-multipath. The uuid of the disk must end
with a letter. 
2. Put a partition on the disk, and rescan it with kpartx to create the /dev/mpath/<uuid>p1 device
3. Run fdisk -l on the /dev/mpath/uuid device.
Actual results:

Note the partition shown is the RHEL 4 convention of /dev/mpath/<uuid>1, not 
/dev/mpath/<uuid>p1 that actually exists in the filesystem

Expected results:

fdisk should show the /dev/mpath/<uuid>p1 device that was actually created.

Additional info:
# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 5.1 (Tikanga)

# uname -a
Linux dreadnought 2.6.18-53.1.21.el5xen #1 SMP Wed May 7 08:57:08 EDT 2008 x86_64 x86_64 
x86_64 GNU/Linux

# ls /dev/mpath/360a9800068714342644a49507a66724b*

# fdisk -l /dev/mpath/360a9800068714342644a49507a66724b

Disk /dev/mpath/360a9800068714342644a49507a66724b: 4294 MB, 4294967296 bytes
256 heads, 56 sectors/track, 585 cylinders
Units = cylinders of 14336 * 512 = 7340032 bytes

                                       Device Boot      Start         End      Blocks   Id  System
/dev/mpath/360a9800068714342644a49507a66724b1               1         585     4193252   83  Linux
Comment 1 Bryn M. Reeves 2009-02-06 09:54:12 EST
The problem is that the partition naming option for the kpartx invocation was changed between RHEL4/RHEL5 from the default heuristic mode (adds a 'p' only if the partition name ends in a letter) to a mode which always adds the p, regardless of the base device name:

$ grep 'kpartx -' RHEL-4/initscripts-*/rc.d/rc.sysinit 
           /sbin/dmsetup ls --target multipath --exec "/sbin/kpartx -a"
           /sbin/dmsetup ls --target multipath --exec "/sbin/kpartx -a"
           /sbin/dmsetup ls --target multipath --exec "/sbin/kpartx -a"

$ grep 'kpartx -' RHEL-5/initscripts-*/rc.d/rc.sysinit 
           /sbin/dmsetup ls --target multipath --exec "/sbin/kpartx -a -p p"
           /sbin/kpartx -a -p p "/dev/mapper/$dmname"

This is unfortunate as quite a few tools (fdisk included) use this same heuristic when constructing partition names:

        /* Heuristic: we list partition 3 of /dev/foo as /dev/foo3,
           but if the device name ends in a digit, say /dev/foo1,
           then the partition is called /dev/foo1p3. */
        w = strlen(disk_device);
        if (w && isdigit(disk_device[w-1]))
Comment 2 Bryn M. Reeves 2009-02-06 10:04:19 EST
I'm don't think util-linux is the correct component for this BZ; the problem was introduced by this change to initscripts:

$ git show 1db1dba1
commit 1db1dba1853f6a3d45b10552ab167f60e156f403
Author: Peter Jones <pjones@redhat.com>
Date:   Thu Aug 31 22:21:28 2006 +0000

   - make multipath partitions be named with the form "${device}p${partnum}",
     like in nash and parted and anaconda and md partitions and...
   - make dmraid partitions be named with "p" as well (and use kpartx)

   diff --git a/rc.d/rc.sysinit b/rc.d/rc.sysinit
   index a1c3e6b..00c105f 100755
   --- a/rc.d/rc.sysinit
   +++ b/rc.d/rc.sysinit
   @@ -411,17 +411,19 @@ if [ -c /dev/mapper/control ]; then
                   modprobe dm-multipath > /dev/null 2>&1
                   /sbin/multipath.static -v 0
                   if [ -x /sbin/kpartx ]; then
   -                       /sbin/dmsetup ls --target multipath --exec "/sbin/kpartx -a"
   +                       /sbin/dmsetup ls --target multipath --exec "/sbin/kpartx -a -p p"
           if [ -x /sbin/dmraid ]; then
                   modprobe dm-mirror >/dev/null 2>&1
   -               for x in $(/sbin/dmraid -ay -t --ignorelocking 2>/dev/null | egrep -iv "^[nN]o " | awk -F ':' '{ print $1 }') ; do
   +               for x in $(/sbin/dmraid -ay -i -p -t 2>/dev/null |
   +                               egrep -iv "^no " |
   +                               awk -F ':' '{ print $1 }') ; do
                           dmname=$(resolve_dm_name $x)
   -                       if [ -z "$dmname" ]; then
   -                               /sbin/dmraid -ay --ignorelocking "$x"
   -                       fi
   +                       [ -n "$dmname" ] && continue
   +                       /sbin/dmraid -ay -i -p "$dmname" >/dev/null 2>&1
   +                       /sbin/kpartx -a -p p "/dev/mapper/$dmname"
I am not entirely convinced by this logic. There's a simple reason why md
devices always have the p - they always end with a numeric character. Same
thing for cciss and the other device types that use this convention. Ordinary
devices like IDE, SCSI etc. follow the same convention - no 'p' since their
base names don't end in numeric characters.

Changing fdisk to use this logic doesn't seem like a good idea as it will cause the wrong names to be shown for devices that were created with the default kpartx options (e.g. user manually running "kpartx -a" to map partitions on a VM's disk image).
Comment 3 Bill Nottingham 2009-02-06 11:20:55 EST
This naming paradigm existed in Fedora for over a year and a half before RHEL 5 was released, and has existed in RHEL 5 GA, 5.1, 5.2, and 5.3.

It's too late to change it; I think the tools need to adapt.
Comment 4 Bryn M. Reeves 2009-02-06 11:28:16 EST
The "if last character is numeric add p" convention is much older than that but it's a moot point.

Any suggestions on how the tools should adapt? I couldn't think of a heuristic for fdisk that will give the right behaviour under all situations short of ripping out the offending bit of code completely and actually going and looking in the file system to determine the right name for a given device.

Maybe that's the right way to go?
Comment 5 Bryn M. Reeves 2009-02-06 11:49:38 EST
Actually that doesn't work for a partition table that has been modified on-disk but that the kernel/kpartx has not yet re-read - "fdisk -l" needs to make up a name for the partitions that matches what would be done if we re-read the partition table.
Comment 6 Bill Nottingham 2009-02-06 11:54:22 EST
Might want to check to see what parted does, and if it suffers from the same problem.
Comment 7 Karel Zak 2009-02-06 16:16:02 EST
It shouldn't be a problem to use "p<N>" for all /dev/mpath/* devices. We (upstream) already have such heuristic for udev devices (/dev/disk/by-*) where the naming paradigm is "-part<N>" (IMHO this paradigm is the best one).
Comment 8 Curtis Gedak 2009-03-16 13:07:41 EDT
(In reply to comment #6)
> Might want to check to see what parted does, and if it suffers from the same
> problem.  

I have been working to add support for dmraid devices in GParted.
See GParted Bug: http://bugzilla.gnome.org/show_bug.cgi?id=317262

I can confirm from my testing that the current git version of parted uses the "if last character of device name is numeric then insert 'p' before the partition number" convention.

In my humble opinion, it would be best if dmraid also followed this convention.
Comment 17 errata-xmlrpc 2011-01-13 18:43:42 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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