Bug 244975 - (user_friendly_names) [NetApp 4.6 bug] Mounting a partitioned dm-mp device using UUID/labels fails on RHEL4 U5
[NetApp 4.6 bug] Mounting a partitioned dm-mp device using UUID/labels fails ...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: mount (Show other bugs)
4.5
All Linux
low Severity medium
: ---
: ---
Assigned To: Karel Zak
Brian Brock
: OtherQA
Depends On:
Blocks: 217206
  Show dependency treegraph
 
Reported: 2007-06-20 07:29 EDT by Rajashekhar M A
Modified: 2009-06-19 19:00 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-03 08:11:55 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)
Terminal logs with exact commands and their output (6.02 KB, text/plain)
2007-06-20 07:29 EDT, Rajashekhar M A
no flags Details
Terminal logs: mount using UUID fails on RHEL 5.0 for partitions (5.52 KB, text/plain)
2007-08-02 02:50 EDT, Rajashekhar M A
no flags Details

  None (edit)
Description Rajashekhar M A 2007-06-20 07:29:34 EDT
Description of problem:
If we create a partition on a dm-mp device and use the UUID of the partition for
mounting, it fails with the following error:
	$ mount UUID=a8a2abcf-28fc-480f-95d4-552eb74e8452 /mnt/filesystem1
	mount: /dev/sdz1 already mounted or /mnt/filesystem1 busy

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

util-linux-2.12a-16.EL4.25
device-mapper-multipath-0.4.5-21.RHEL4

How reproducible:
Always

Steps to Reproduce:

(Assume that the dm-mp device is /dev/mapper/mpath2 on which we want to create
partitions and mount it using its UUID. Also assume that there are 4 underlying
SCSI paths for it viz., /dev/sdz, /dev/sdg, /dev/sdf/, /dev/sdr)

1. Create a partition on one of the underlying SCSI devices using fdisk:
	$ fdisk /dev/sdz

2. Verify that the device partition i.e. /dev/sdz1 is updated in the partition
table by checking the /proc/partitions.

3. Now run kpartx to reflect the partition in the dm-mp layer:
	$ kpartx -a /dev/mapper/mpath2

4. Verify that the dm-mp partition is updated in the partition table by checking
the /proc/partitions.
	(Assume that the new dm-mp device for the partition is /dev/mapper/mpath2p1).

5. Create a file system on the dm-mp partition device
	$ mke2fs -j /dev/mapper/mpath2p1

6. Get the UUID of the dm-mp partition by running:
	$ dumpe2fs /dev/mapper/mpath2p1 | grep UUID

7. Assume that the UUID is a8a2abcf-28fc-480f-95d4-552eb74e8452. Now mount the
above partiton:
	$ mount UUID=a8a2abcf-28fc-480f-95d4-552eb74e8452 /mnt/filesystem1

8. The mount fails with the following error:
	$ mount UUID=a8a2abcf-28fc-480f-95d4-552eb74e8452 /mnt/filesystem1
	mount: /dev/sdz1 already mounted or /mnt/filesystem1 busy


Actual results:
Mount fails with an error similar to -
	mount: /dev/sdz1 already mounted or /mnt/filesystem1 busy


Expected results:
The mount should have succeeded without any errors.

Additional info:

1. Using labels for dm-mp partitions also fails. In this case, the error message
thrown is as follows: 
         mount: LABEL=mpath0p1 duplicate - not mounted
2. On RHEL5, both mounting by UUID/labels succeed for dm-mp partitions.
3. Attached - terminal logs with the actual commands run on a RHEL4 U5 host.
Comment 1 Rajashekhar M A 2007-06-20 07:29:34 EDT
Created attachment 157449 [details]
Terminal logs with exact commands and their output
Comment 2 Rajashekhar M A 2007-06-25 12:44:34 EDT
An update; this issue is seen on RHEL5 as well.
Comment 3 RHEL Product and Program Management 2007-06-28 10:05:38 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 4 Ben Marzinski 2007-07-23 16:48:13 EDT
I don't know what to do with this one. The filesystem label and uuid are
properties of the filesystem.  There is no way that multipath can tinker with
them, so it is up to mount to handle this correctly. The problem here is that
the multipath device, and all of the underlying devices all have the exact same
view of the filesystem.  So you will have multiple devices with the same UUID
and label. Since the device-mapper devices aren't scanned for UUIDs until after
the scsi devices, and mount simply picks the first device with a matching UUID,
you will always fail when trying to mount via UUID.  Without a patch to mount,
there is no way to handle UUIDs at all.  Labels work differently.  If you have
multiple devices with the same Label, mount looks in /etc/fstab.order to if any
of the devices have a higher priority. So, labels can be handled writing the
multipath device (i.e. /dev/mapper/mpath0p1) to /etc/fstab.order.

Of course all this begs the question of why mounting by UUIDs or labels is so
important with multipath devices.  Multipath already guarantees that multipath
device names will be consistent across reboots. However, if you use the
user_friendly_names option in /etc/multipath.conf, these names are not
guaranteed to be consistent across nodes.  To solve this, either do not select
user_friendly_names in /etc/multipath.conf, or once you have the multipath
devices set up on one machine, copy /var/lib/multipath/bindings to the other
machines. This will cause the same user_friendly_names to be used on all of the
machines.

If this is not a good enough solution, then this bug should probably be switched
to a mount bug (part of the util-linux package).  There are a number of ways
that mount could deal with this.  For instance, it could try to resolve
duplicate UUIDs the same way that it does duplicate labels. Also, mount would
need to allow you to either restrict the devices that you checked when scanning
for a label or UUID, or set up some sort of by-type ordering, so that
device-mapper devices always had a higher priority than regular devices. These
two changes would allow multipath to work with UUIDs and labels. 
Comment 5 Martin George 2007-07-27 08:26:24 EDT
Ok..we are fine not using UUIDs or labels for mounting dm-mp devices. 

It would be good if we could have the same UUID implementation as done for labels.
Comment 6 Ben Marzinski 2007-07-31 18:25:10 EDT
I'm switching this to be a mount bug, since multipath can't do anything about
how mount selects devices by UUID or label.
Comment 7 Karel Zak 2007-07-31 19:32:54 EDT
(In reply to comment #2)
> An update; this issue is seen on RHEL5 as well.

mount(8) in RHEL5 uses dependence tree and it should be able to found the right
device.
Comment 8 Rajashekhar M A 2007-08-02 02:47:20 EDT
It fails in RHEL5 also with the same steps as in the descrition. However, if we
don't create partitions on the dm-mp device, mount using UUID succeeds. But if
we create partitions on the dm-mp device and try to mount a partition using
UUIDs, it fails. Please see the attachment for command outputs on a RHEL 5.0
machine.

The attachment shows the mount succeeding on a whole dm-mp device, but failing
on a partition.
Comment 9 Rajashekhar M A 2007-08-02 02:50:18 EDT
Created attachment 160500 [details]
Terminal logs: mount using UUID fails on RHEL 5.0 for partitions
Comment 11 RHEL Product and Program Management 2007-08-03 08:11:55 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request. 
Comment 13 Andrius Benokraitis 2007-08-03 11:24:36 EDT
NetApp: Red Hat Engineering has deemed that there is no clear solution for this
issue, therefore the result being CLOSED.

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