Multipath module currently needs access to scsi_id and related udev device properties

[bmarzins]

The way that the libmpathvalid library currently works, mpath_is_path() calls udev_device_get_property_value() to check the appropriate udev property for the multipath WWID. For scsi devices this depends on either scsi_id and the ID_SERIAL rules from 60-persistent-storage.rules (for redhat) or sg_inq and the ID_SERIAL rules from 55-scsi-sg3_id.rules (for everyone else, I think). For NVMe devices, it is the wwid sysfs attribute set to ID_WWN in 60-persistent-storage.rules. For DASD devices, it is dasdinfo and the ID_UID rules from 59-dasd.rules. Since sid runs before any of these rules are called, this information isn't available to mpath_is_path().

One way to deal with these issues would be for SID to gather all of this information for itself. However, aside from this being a lot of work, not all distributions set ID_SERIAL for scsi devices based on the same rules. I believe that Red Hat is the odd one out, and it's definitely possible that it will change to using 55-scsi-sg3_id.rules to set ID_SERIAL in future releases. But it's not possible to be sure that all distributions use the same rules in the same order. To make sure that multipath is claiming devices correctly, the WWID that libmpathvalid sees has to match the WWID that multipathd sees. If the information that SID gathers doesn't match what is set by later running udev rules, it's possible that multipath and multipathd will disagree on the WWID.

Another way to deal with this issue, which is perhaps easier, is to make libmpathvalid and multipathd not rely on udev for the WWID, if run on a system with SID. The multipath code currently has failback methods for gathering SCSI and NVMe WWIDS from sysfs. Adding code to get DASD wwids from sysfs wouldn't be much extra work. If SID is running, libmpathvalid and multipathd can both use these failback methods as the primary method, and ignore the udev properties completely.

This only leaves one problem, which is shared with the previous method. Currently if the existing configured udev property doesn't work as a WWID for some device, it's trivial to pick a different property, and use that, or even add a new udev rules to create a new property that multipath can use for the WWID. With SID, this is no longer as easy. However, multipath currently has a deprecated option that defines a callout program which can be run to get the WWID. If this option was un-deprecated, it could be used as a backup for cases where the existing sysfs methods to get a WWID don't work of for a specific situation.

[prajnoha]

The infotmation provided by scsi_id is a kind of information that, in SID terms, belongs to IDENT-TYPE phase - I'll update the sheet to include this one (https://docs.google.com/spreadsheets/d/1yhCgrC_oX30MjV2hPpFxMd90p_tK01Ct5kDXorMpILI/edit#gid=1526719739). This means, we detect first that we have a SCSI-type device (in IDENT-CORE) and then we execute type-specific identification for this device type (that is the IDENT-TYPE).

I'll check if we could port the scsi_id code to SID - there shouldn't be any change needed to that code except that at the very end, we write the information to SID db instead of importing that to udev db (udev db will have that from SID instead then). The scsi_id code is currently a part of systemd/udev directly.

[prajnoha]

Regarding scsi_id in systemd/udevd - there's some relatively less and more recent discussion ongoing about this in systemd/systemd#7594 As I understood, this intends to remove scsi_id completely from udev and using the tools/libs from sg3_utils instead. It's probably worth looking into the library whether it's something we could use inside SID too.