Can we use libblkid to determine whether a device is a multipath member?

[mulkieran]

Currently, in find_all, all uninitialized udev devices are ignored when enumerating Stratis devices. I believe that the reason for this is that multipath member devices must be filtered out, and they might not be properly identified if the device is uninitialized. If there was an alternative way, then the stratis enumeration could sweep up all ID_FS_TYPE=stratis devices and a post-check could be done to screen out the multipath members.

[mulkieran]

@jbaublitz Could you make a note of where we are so far on this?

[jbaublitz]

Absolutely.

blkid does not seem able to detect this.

So far we've discovered two ways that we can detect a multipath member.

1. Rely on udev. We already do this and based on some testing I've done, this seems to work quite nicely despite the code being a bit dependent on udev's database format remaining static.
2. Rely on devicemapper. This brings up the question of race conditions per my discussion with @drckeefe yesterday. If multipathd sets up the devicemapper node unifying the multiple paths after stratisd comes up, this may not be a reasonable way the filter out devices as it is dependent on the multipath top level device being present.

There may be an additional check we can do using sysfs depending on if there's a uniform way to detect that a storage device has come up as a multipath device. We're still looking into possibilities around this option. If this is possible, this is probably the most reliable.

[mulkieran]

Taking this off any board, as we've done investigation and using blkid likely won't help.

[jbaublitz]

@prajnoha Just wanted to follow up on this. Is there any /sys fs way to detect if a device is a multipath device? Or is this best handled by udev?

[prajnoha]

The only way how to detect this is to compare devices' identifiers (WWIDs). Some of them can be read directly from /sys, but there are also other ways and exceptions and it's not just one source - device-mapper-multipath contains a logic and priorities in its code to return proper identifiers here and based on them declare a device as being a multipath path.

So the best way is to rely on device-mapper-multipath itself. We can do this either:

• By reading the udev variables where dm-mpath udev rules export this information - it is DM_MULTIPATH_DEVICE_PATH="1" or it also sets ID_FS_TYPE="mpath_member" (set by /usr/lib/udev/rules.d/62-multipath.rules - if you're going to consume this inside your udev rule, it needs to go after those 62-multipath.rules);

• Or by using device-mapper-multipath's libmpathvalid library which should be able to export this as well (in Fedora, it's part of device-mapper-multipath-devel package).

Usually, the mpath rules/libmpathvalid declare a device as being a multipath path directly if the device (its identifier) is mentioned in multipath configuration. However, if it's missing in the configuration, multipath can use a mode in which it first claims all devices as a multipath path (well, the ones which can be multipathed: scsi, nvme, dasd...), waits till some timeout and if it sees another device with the same identifier within the timeout, it confirms that this is its path. Otherwise, it drops the claim. This is called smart mode and it is configured in mpath configuration, see also find_multipaths and its smart option in man multipath.conf. Anyway, if you read the mpath's udev variables, it should all be handled correctly by mpath rules already and it should just work.

It looks that the most straightforward way is the udev way.