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
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
