From: Benjamin Marzinski <bmarzins@redhat.com>
To: Christophe Varoqui <christophe.varoqui@opensvc.com>
Cc: device-mapper development <dm-devel@redhat.com>,
Martin Wilck <mwilck@suse.com>
Subject: [PATCH v2 00/12] Misc Multipath patches
Date: Fri, 8 Mar 2019 17:11:53 -0600 [thread overview]
Message-ID: <1552086725-18476-1-git-send-email-bmarzins@redhat.com> (raw)
The series is a mix of resends an new patches.
Patches 0001-0005 are simply resends of patches I've submitted earlier,
with no changes other that adding Reviewed-by's where appropriate.
Patches 0006-0009 are the result of running into some bugs during
firmare updates on an array.
Changes in v2:
0007: simply fixes the issue with multipathd not resetting the wwid
when get_uid() fails, and makes scsi_uid_fallback return the
correct value, when it is still waiting for the retriggers
to max out. The Changes that Martin suggested are dealt with
in patch 0012
0010: This patch adds some missing options to the multipath.conf(5)
man page, including "user_friendly_names" like Martin metioned
in his earlier review of patch 0001.
0011: This patch adds a fallback method for nvme devices, to grab the
wwid directly from sysfs.
0012: I kept this patch seperate from 0007, because I'm not sure that
it is the right thing to do. First, it's not very hard to have
get_uid() fail. For a scsi device, all that needs to happen is
for a change event to occur while the path is down and cannot be
opened. scsi_id will fail, and ID_SERIAL will not be set. This
seems far more likely than a device changing wwids because it
switched LUNs.
If we fail the device for getting a blank wwid, we then have to
get the new wwid before we can decide what needs to be done to
the path. There are two options. One is to trigger more
uevents, so that multipathd gets a uevent with the updated
uid_attribute. This assumes that the original problem wasn't
udev timing out because it was overloaded. If that was the
problem, adding more uevents just makes things work. Even
still, this means that once the new wwid is available, we have
to run check_path, then wait for the uevent, and then run
check_path again before we can restore the path. For these
reasons, I didn't go down this route.
The other way to get the new wwid is to run the fallback
methods. This doesn't require multipathd to get a new uevent
with the updated wwid, but it does do something that worries
me. When we run the fallback methods, we clear uid_attribute
for the path. We do this because, presumably, we can't be
certain that the fallback method and the uid_attribute method
will return the same wwid. If this is really a possiblity
then the fallback methods aren't any help at all. I don't
know of any cases where this is true, which is why I'm
submitting the patch. But I still not sure that its not
better simply to assume that if get_uid() fails, that it
did so for some mundane reason, and simply keep the old
wwid.
Benjamin Marzinski (12):
libmultipath: disable user_friendly_names for NetApp
libmultipath: handle existing paths in marginal_path enqueue
multipathd: cleanup marginal paths checking timers
libmultipath: fix marginal paths queueing errors
libmultipath: fix marginal_paths nr_active check
multipathd: Fix miscounting active paths
multipathd: ignore failed wwid recheck
libmutipath: continue to use old state on PATH_PENDING
multipathd: use update_path_groups instead of reload_map
multipath.conf: add missing options to man page
libmultipath: add get_uid fallback code for NVMe devices
multipathd: change failed get_uid handling
libmultipath/discovery.c | 73 +++++++++++++++++++++++++-------------
libmultipath/hwtable.c | 1 +
libmultipath/io_err_stat.c | 71 +++++++++++++++---------------------
libmultipath/io_err_stat.h | 2 +-
libmultipath/structs.h | 6 ++++
multipath/main.c | 2 +-
multipath/multipath.conf.5 | 8 +++++
multipathd/cli_handlers.c | 2 +-
multipathd/main.c | 50 ++++++++++++++++++--------
multipathd/main.h | 2 ++
10 files changed, 133 insertions(+), 84 deletions(-)
--
2.17.2
next reply other threads:[~2019-03-08 23:11 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-08 23:11 Benjamin Marzinski [this message]
2019-03-08 23:11 ` [PATCH v2 01/12] libmultipath: disable user_friendly_names for NetApp Benjamin Marzinski
2019-03-17 15:04 ` Xose Vazquez Perez
2019-03-18 9:45 ` Martin Wilck
2019-03-08 23:11 ` [PATCH v2 02/12] libmultipath: handle existing paths in marginal_path enqueue Benjamin Marzinski
2019-03-08 23:11 ` [PATCH v2 03/12] multipathd: cleanup marginal paths checking timers Benjamin Marzinski
2019-03-08 23:11 ` [PATCH v2 04/12] libmultipath: fix marginal paths queueing errors Benjamin Marzinski
2019-03-08 23:11 ` [PATCH v2 05/12] libmultipath: fix marginal_paths nr_active check Benjamin Marzinski
2019-03-08 23:11 ` [PATCH v2 06/12] multipathd: Fix miscounting active paths Benjamin Marzinski
2019-03-08 23:12 ` [PATCH v2 07/12] multipathd: ignore failed wwid recheck Benjamin Marzinski
2019-03-15 11:48 ` Martin Wilck
2019-03-19 17:13 ` Benjamin Marzinski
2019-03-08 23:12 ` [PATCH v2 08/12] libmutipath: continue to use old state on PATH_PENDING Benjamin Marzinski
2019-03-08 23:12 ` [PATCH v2 09/12] multipathd: use update_path_groups instead of reload_map Benjamin Marzinski
2019-03-15 11:49 ` Martin Wilck
2019-03-08 23:12 ` [PATCH v2 10/12] multipath.conf: add missing options to man page Benjamin Marzinski
2019-03-15 11:49 ` Martin Wilck
2019-03-19 17:14 ` Benjamin Marzinski
2019-03-08 23:12 ` [PATCH v2 11/12] libmultipath: add get_uid fallback code for NVMe devices Benjamin Marzinski
2019-03-15 11:49 ` Martin Wilck
2019-03-19 17:15 ` Benjamin Marzinski
2019-03-20 7:55 ` Martin Wilck
2019-03-08 23:12 ` [PATCH v2 12/12] multipathd: change failed get_uid handling Benjamin Marzinski
2019-03-15 11:50 ` Martin Wilck
2019-03-19 17:20 ` Benjamin Marzinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1552086725-18476-1-git-send-email-bmarzins@redhat.com \
--to=bmarzins@redhat.com \
--cc=christophe.varoqui@opensvc.com \
--cc=dm-devel@redhat.com \
--cc=mwilck@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.