[dm-devel] [PATCH v2 00/12] Misc Multipath patches

[Benjamin Marzinski]

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