Bug 244975 (user_friendly_names)
| Summary: | [NetApp 4.6 bug] Mounting a partitioned dm-mp device using UUID/labels fails on RHEL4 U5 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Rajashekhar M A <rajashekhar.a> | ||||||
| Component: | mount | Assignee: | Karel Zak <kzak> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 4.5 | CC: | agk, andriusb, bmarzins, christophe.varoqui, coughlan, dwysocha, egoggin, junichi.nomura, kueda, lmb, marting, mbroz, prockai, rsarraf, tranlan, xdl-redhat-bugzilla | ||||||
| Target Milestone: | --- | Keywords: | OtherQA | ||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2007-08-03 12:11:55 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 217206 | ||||||||
| Attachments: |
|
||||||||
Created attachment 157449 [details]
Terminal logs with exact commands and their output
An update; this issue is seen on RHEL5 as well. 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. 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. 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. I'm switching this to be a mount bug, since multipath can't do anything about how mount selects devices by UUID or label. (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. 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. Created attachment 160500 [details]
Terminal logs: mount using UUID fails on RHEL 5.0 for partitions
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request. NetApp: Red Hat Engineering has deemed that there is no clear solution for this issue, therefore the result being CLOSED. |
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.