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