Cloning for libdevmapper part of this fix for F18.

+++ This bug was initially created as a clone of Bug #864368 +++

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:

--- Additional comment from xiaoli on 2012-10-09 11:03:42 CEST ---

close it if it's by design.

--- Additional comment from prajnoha on 2012-10-09 11:44:00 CEST ---

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.

--- Additional comment from bmarzins on 2012-10-23 05:31:24 CEST ---

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.

--- Additional comment from prajnoha on 2012-10-23 13:37:22 CEST ---

(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).

--- Additional comment from prajnoha on 2012-10-23 13:40:07 CEST ---

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)

--- Additional comment from prajnoha on 2012-10-23 14:00:17 CEST ---

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.

--- Additional comment from prajnoha on 2012-10-23 14:04:59 CEST ---

Created attachment 632052 [details]
complete patch to use DM_UDEV_DISABLE_LIBRARY_FALLBACK in mpath tools

...attaching complete patch for mpath tools

--- Additional comment from prajnoha on 2012-10-23 14:07:20 CEST ---

Created attachment 632055 [details]
complete patch to use DM_UDEV_DISABLE_LIBRARY_FALLBACK in mpath tools

--- Additional comment from bmarzins on 2012-10-23 16:45:23 CEST ---

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.

--- Additional comment from bmarzins on 2012-10-23 19:43:54 CEST ---

Peter, is the libdm fix making it into f18?

--- Additional comment from prajnoha on 2012-10-24 09:17:45 CEST ---

(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...

--- Additional comment from bmarzins on 2012-10-25 06:31:36 CEST ---

Patch applied. Thanks.  Note to testers: this still needs the libdm fix for it to actually do anything.

--- Additional comment from updates on 2012-10-25 06:35:54 CEST ---

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

--- Additional comment from updates on 2012-10-26 21:35:01 CEST ---

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).