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

[ChristianEhrhardt]

On Mon, Nov 28, 2016 at 9:13 AM, Hua Zhang <joshua.zhang at canonical.com>
wrote:

> Does newer multipath-tools mean multipath-tools>=6.1 you mentioned
> above, if yes, the fixed patch has been already in it. It's too great to
> have with that approach -:)
>

Would be 6.3 and yes due to that I'd not need the zesty debdiff.


> BTW, do we have the tracking link to know the process status for the
> newer multipath-tools merge work, and an estimate about how long it will
> take? thanks.
>

There is no extra tracking, but I already included this bug in the
changelog.
So once an upload appears this bug will get updated.

The initial merge is more or less done, the next stages will be about
Testing the new revision and reviewing my merge.
I'll add you onto the related bugs and reviews so that you are updated on
the status.


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1621340

Title:
  [SRU]'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