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:
close it if it's by design.
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.
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.
(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).
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)
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.
Created attachment 632052 [details] complete patch to use DM_UDEV_DISABLE_LIBRARY_FALLBACK in mpath tools ...attaching complete patch for mpath tools
Created attachment 632055 [details] complete patch to use DM_UDEV_DISABLE_LIBRARY_FALLBACK in mpath tools
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.
Peter, is the libdm fix making it into f18?
(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...
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
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).
verified in lvm2-2.02.98-2.fc18.x86_64