[Bug 1621340] Re: [SRU]'multipath -r' causes /dev/mapper/<wwid> being removed

Hua Zhang joshua.zhang at canonical.com
Thu Feb 16 11:30:12 UTC 2017


Verified successfully on both xenial-proposed and yakkety-proposed.

The test result can refer the link [1], and I refer the link [2] to set
up the test env.

Before applying the patch we can see:

Feb 16 08:52:45 juju-zhhuabj-machine-9 systemd[13815]: dev-disk-by
\x2did-scsi\x2d360000000000000000e00000000010001.device: Dev dev-disk-by
\x2did-scsi\x2d360000000000000000e00000000010001.device appeared twice
with different sysfs paths
/sys/devices/platform/host13/session12/target13:0:0/13:0:0:1/block/sda
and /sys/devices/virtual/block/dm-0

After applying the patch we can see:

Feb 16 09:06:10 juju-zhhuabj-machine-9 systemd-udevd[21289]: conflicting
device node '/dev/mapper/360000000000000000e00000000010001' found, link
to '/dev/dm-0' will not be created

[1] http://pastebin.ubuntu.com/24006257/
[2] https://gist.github.com/niedbalski/ae85dac1a3ea0b82ad05

** Tags removed: verification-needed
** Tags added: verification-done

** Tags added: verification-xenial-done verification-yakkety-done

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1621340

Title:
  [SRU]'multipath -r' causes /dev/mapper/<wwid> being removed

Status in multipath-tools package in Ubuntu:
  Fix Released
Status in multipath-tools source package in Xenial:
  Fix Committed
Status in multipath-tools source package in Yakkety:
  Fix Committed

Bug description:
  [Impact]

  "multipath -r" causes the /dev/mapper/<wwid> to disappear momentarily,
  which leads to some issue in consumer applications as such OpenStack.

  [Test Case]

   * connect to an multipath iscsi target
   * multipath -r
   * /dev/mapper/<wwid> disappears momentarily

  [Regression Potential]

   * None

  
  "multipath -r" causes the /dev/mapper/<wwid> to disappear momentarily, which leads to some issue in consumer applications as such OpenStack. After some investigation, I found that /dev/mapper/<wwid> was deleted by udev during the reload, and it was re-created soon later by multipathd (livdevmapper code of cause).  Detailed findings are as follows:

  For reload in domap (rename as well),

          case ACT_RELOAD:
                  r = dm_addmap_reload(mpp, params);
                  if (r)
                          r = dm_simplecmd_noflush(DM_DEVICE_RESUME, mpp->alias,
                                                   0, MPATH_UDEV_RELOAD_FLAG);
                  break;

  it passes 0 to dm_simplecmd_noflush as argument for needsync, which
  makes dm_task_set_cookie call being skipped in dm_simplecmd,

          if (udev_wait_flag && !dm_task_set_cookie(dmt, &cookie, ((conf->daemon)? DM_UDEV_DISABLE_LIBRARY_FALLBACK : 0) | udev_flags)) {
                  dm_udev_complete(cookie);
                  goto out;
          }

  because of the short-circuit evaluation. Thus _do_dm_ioctl in
  libdevmapper will add DM_UDEV_DISABLE_DM_RULES_FLAG flag to
  dmi->event_nr, and that will eventually be used in the udev rules
  (55-dm.rules),

  ENV{DM_UDEV_DISABLE_DM_RULES_FLAG}!="1", ENV{DM_NAME}=="?*",
  SYMLINK+="mapper/$env{DM_NAME}"

  Since the DM_UDEV_DISABLE_DM_RULES_FLAG is set, the rule will not
  match. As a result the link is removed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1621340/+subscriptions



More information about the foundations-bugs mailing list