[dm-devel] [PATCH 2/2] multipathd: add recheck_wwid_time option to verify the path wwid

[Benjamin Marzinski]

On Tue, Feb 09, 2021 at 10:19:45PM +0000, Martin Wilck wrote:
> On Mon, 2021-02-08 at 23:19 -0600, Benjamin Marzinski wrote:
> >  If
> > multipathd notices that a path's wwid has changed it will remove and
> > re-add the path, just like the existing wwid checking code for change
> > events does.  In cases where the no uevent occurs, both the udev
> > database entry and sysfs will have the old wwid, so the only way to
> > get
> > a current wwid is to ask the device directly. 
> 
> sysfs is wrong too, really? In that case I fear triggering an uevent
> won't fix the situation. You need to force the kernel to rescan the
> device, otherwise udev will fetch the WWID from sysfs again, which
> still has the wrong ID... or what am I missing here?

I just figured out the confusion here.  Redhat has not always included
55-scsi-sg3_id.rules in sg3_utils. It does now, but installs it as
61-scsi-sg3_id.rules instead (This is why we install multipath.rules as
62-multipath.rules). The result of this is that ID_SERIAL is set by
"scsi_id --export --whitelisted -d $devnode" from
60-persistent-storage.rules. This means that when a uevent comes in,
ID_SERIAL is repopulated by ioctling the device, unlike the case where
55-scsi-sg3_id.rules sets ID_SERIAL, which gets the information from
sysfs if possible.

Clearly, for distributions that set ID_SERIAL from 55-scsi-sg3_id.rules,
multipathd needs to take more drastic measures if the sysfs vpd_page83
file is wrong.

Looking at this made me notice another issue. scsi_id and the rules in
55-scsi-sg3_id.rules don't agree on the priority of the different id
types for choosing the wwid from the various ids in vpd page 83. And
mulitpath's parse_vpd_pg83() doesn't agree with either of them.

Here are the different priority orderings for the ID types

		sg_inq +
scsi_id		55-scsi-sg3_id.rules	parse_vpd_pg83
-------------------------------------------------------
36		36			36
35		35			35
3[^56]		32			32
2		2			8
		8			2
1		1			1
		3[^652]			3[^652]
0		0			0

Since Redhat is changing the default ordering of the
55-scsi-sg3_id.rules, it seems reasonable that we make parse_vpd_pg83()
match the 55-scsi-sg3_id.rules ordering, and I'll add a redhat specific
patch to match it to the scsi_id ordering. However, the fact that
differences which udev rules are installed or their ordering can changed
the WWID does lend some weight to the code that I originally had for
recheck_wwid, where we would only enable it after verifying that at one
point, the parse_vpd_pg83() wwid agreed with the uid_attribute wwid. On
the other hand, assuming that distributions make sure that
parse_vpd_pg83() matches their udev setup, then not requiring them to be
equal at some point allows recheck_wwid to catch problems that happened
before multipath started using the device, for whatever that's worth.

-Ben