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

[ChristianEhrhardt]

Hi Hua,
this is broken in zesty as well, but there it should/will be fixed by a merge of multipath-tools >=6.1
Thank you for the debdiff on X&Y.

I had to look up as I wanted to check if this is already upstream, it would be very kind if you could add valid dep3 headers to your patches http://dep.debian.net/deps/dep3/
Especially in cases like this it helps reviewers to quickly find if and where such a patch is already upstream.

The patches themself looks correct to me, if you would refresh them that would be great.
I'll add a Yakkety task already.

Then following the SRU policy this should be in Zesty before doing the
SRUs - but I didn't hear anybody stating that they are working on
multipath-tools merge already - I'll ask around.

-- 
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:
  'multipath -r' causes /dev/mapper/<wwid> being removed

Status in multipath-tools package in Ubuntu:
  In Progress
Status in multipath-tools source package in Xenial:
  In Progress

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