Bug 864368 - /dev/mapper/mpathX is block device not symbolic link
/dev/mapper/mpathX is block device not symbolic link
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: device-mapper-multipath (Show other bugs)
18
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Ben Marzinski
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F18Betappc 869253 869254 872174
  Show dependency treegraph
 
Reported: 2012-10-09 05:03 EDT by Xiaowei Li
Modified: 2015-01-26 19:10 EST (History)
13 users (show)

See Also:
Fixed In Version: device-mapper-multipath-0.4.9-35.fc18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 869253 869254 872174 (view as bug list)
Environment:
Last Closed: 2012-11-28 12:23:37 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
kpartx patch to use DM_UDEV_DISABLE_LIBRARY_FLAG (732 bytes, patch)
2012-10-23 07:40 EDT, Peter Rajnoha
no flags Details | Diff
complete patch to use DM_UDEV_DISABLE_LIBRARY_FALLBACK in mpath tools (732 bytes, patch)
2012-10-23 08:04 EDT, Peter Rajnoha
no flags Details | Diff
complete patch to use DM_UDEV_DISABLE_LIBRARY_FALLBACK in mpath tools (1.87 KB, patch)
2012-10-23 08:07 EDT, Peter Rajnoha
no flags Details | Diff

  None (edit)
Description Xiaowei Li 2012-10-09 05:03:07 EDT
Description of problem:


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


How reproducible:


Steps to Reproduce:
# rpm -q device-mapper-multipath
device-mapper-multipath-0.4.9-29.fc18.x86_64
# uname -a
Linux storageqe-02-iscsi1.lab.bos.redhat.com 3.6.0-3.fc18.x86_64 #1 SMP Wed Oct 3 13:29:15 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
#ls -l /dev/mapper/
total 0
crw-------. 1 root root  10, 236 Oct  7 20:46 control
brw-rw----. 1 root disk 253,   0 Oct  7 20:46 mpathb
brw-------. 1 root root 253,   1 Oct  7 20:46 mpathbp1
brw-------. 1 root root 253,   2 Oct  7 20:46 mpathbp2
lrwxrwxrwx. 1 root root        7 Oct  7 20:46 vg_storageqe--02--iscsi1-lv_root -> ../dm-4
lrwxrwxrwx. 1 root root        7 Oct  7 20:46 vg_storageqe--02--iscsi1-lv_swap -> ../dm-3
lrwxrwxrwx. 1 root root        7 Oct  7 20:46 VolGroup00-LogVol00 -> ../dm-5
lrwxrwxrwx. 1 root root        7 Oct  7 20:46 VolGroup00-LogVol01 -> ../dm-6

  
Actual results:


Expected results:


Additional info:
Comment 1 Xiaowei Li 2012-10-09 05:03:42 EDT
close it if it's by design.
Comment 2 Peter Rajnoha 2012-10-09 05:44:00 EDT
If there are nodes instead of symlinks in /dev/mapper, it means that libdevmapper was used in "non-udev" mode and there was a fallback to original direct node creation in libdevmapper, bypassing the udev.

Mpath should work now with udev support/udev synchronisation enabled by default so the situation described here is a fallback in case there's something wrong with udev setup.

As for kpartx and mappings created for partitions defined on top of an mpath device, it has an extra "-s" parameter to enable udev synchronisation (kpartx is called within udev rules directly to automatically create these mappings).

Ben, I've noticed there's still "kpartx" call without "-s" in 62-multipath.rules: 

  RUN+="$env{MPATH_SBIN_PATH}/kpartx -a -p p $tempnode"

We should change that to use the "-s" as well... Otherwise the device is not visible from udev database accessible from libudev etc. and that one could be used as a primary source of information for the list of existing devices in the system - LVM uses that for example and if udev is bypassed, the device is not seen by LVM then (or any other subsystem using udev DB).

That's for kpartx, though I'm not quite sure now why the non-partition mpath mappings bypassed udev.
Comment 3 Ben Marzinski 2012-10-22 23:31:24 EDT
Is there any way to tell libdevmapper that I want udev to create the device, but I don't want to wait for that to get done? I'm really leery of having kpartx, which is called from udev, wait on udev.
Comment 4 Peter Rajnoha 2012-10-23 07:37:22 EDT
(In reply to comment #3)
> Is there any way to tell libdevmapper that I want udev to create the device,
> but I don't want to wait for that to get done? 

Yup... However, I see another part of the problem now! The libdm part was not correctly passing flags that control udev supporting code in case udev_sync is not used! The DM_UDEV_DISABLE_LIBRARY_FALLBACK was not propagated internally while udev_sync is off, it should be fixed with this patch (I'll include that in next 6.4 build):

  http://git.fedorahosted.org/cgit/lvm2.git/commit/?id=a820a68619c10108666f8093545837233c954046

Another part of the fix is for kpartx that should use the above-mentioned flag to control libdm to not try fixing any nodes and symlinks (in case udev_sync is not used - actually, this is the preferred way as, otherwise, there's a race between udev and libdm with respect to node creation without udev_sync. So we need to gracefully let udev do the work and disable any further checks and fallbacks to direct node creation).
Comment 5 Peter Rajnoha 2012-10-23 07:40:07 EDT
Created attachment 632040 [details]
kpartx patch to use DM_UDEV_DISABLE_LIBRARY_FLAG

Patch for kpartx attached... (we should probably make this a default setting in libdm)
Comment 6 Peter Rajnoha 2012-10-23 08:00:17 EDT
The use of DM_UDEV_DISABLE_LIBRARY_FLAG will cause libdm to rely on udev completely to create nodes and symlinks, libdm itself will not try any checks and it won't do any corrections with this flag used.

Ben, it's up to you - you may use this flag conditionally (e.g. dmsetup uses "--verifyudev" to not use this flag and do any corrections if udev did not create the nodes/symlinks for some reason, but by default, it makes use of it). Though, the library fallback should be just for debug, I think - if udev works correctly, there's no reason to have missing nodes/symlinks even if completely relying on udev.
Comment 7 Peter Rajnoha 2012-10-23 08:04:59 EDT
Created attachment 632052 [details]
complete patch to use DM_UDEV_DISABLE_LIBRARY_FALLBACK in mpath tools

...attaching complete patch for mpath tools
Comment 8 Peter Rajnoha 2012-10-23 08:07:20 EDT
Created attachment 632055 [details]
complete patch to use DM_UDEV_DISABLE_LIBRARY_FALLBACK in mpath tools
Comment 9 Ben Marzinski 2012-10-23 10:45:23 EDT
Peter. Thanks for the fix.  The only place where I'm worried about relying on udev is in anaconda. I'll talk with them to see if multipath and kpartx don't need to be able to create devices there.  But fixing that is easy.
Comment 10 Ben Marzinski 2012-10-23 13:43:54 EDT
Peter, is the libdm fix making it into f18?
Comment 11 Peter Rajnoha 2012-10-24 03:17:45 EDT
(In reply to comment #10)
> Peter, is the libdm fix making it into f18?

I need to do an update for f18 - I have that in plan actually (together with other fixes and changes). Unfortunately, the f18 beta change deadline was yesterday but I'll try to push the update anyway if still possible...
Comment 13 Fedora Update System 2012-10-25 00:35:54 EDT
device-mapper-multipath-0.4.9-35.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/device-mapper-multipath-0.4.9-35.fc18
Comment 14 Fedora Update System 2012-10-26 15:35:01 EDT
Package device-mapper-multipath-0.4.9-35.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing device-mapper-multipath-0.4.9-35.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-16907/device-mapper-multipath-0.4.9-35.fc18
then log in and leave karma (feedback).
Comment 17 Xiaowei Li 2012-11-28 04:45:09 EST
verified in lvm2-2.02.98-2.fc18.x86_64

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