You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to configure multipath on a device which has only one path (/dev/sdd). (This is for testing, but I believe there may be uses for this even in production, e.g. when only one path exists for a device, but one knows that more paths will appear.)
I tried to do this via adding the device to the wwids file (multipath -a /dev/sdd) and restarting multipathd (systemctl restart multipathd), which then picks up the device and creates the multipath map (/dev/mapper/mpatha). This mostly works, but I have encountered an irregularity where udevadm info on the path does not show that it is a path:
# udevadm info /dev/sdd
E: DM_MULTIPATH_DEVICE_PATH=0
Also, there are still partition device nodes on /dev/sdd (they should have been deleted by /usr/lib/udev/rules.d/68-del-part-nodes.rules):
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdd 8:48 0 558.9G 0 disk
├─sdd1 8:49 0 558.9G 0 part
└─mpatha 253:3 0 558.9G 0 mpath
└─mpatha1 253:4 0 558.9G 0 part
This gets corrected after reboot, udevadm info shows the expected results:
# udevadm info /dev/sdd
E: DM_DEL_PART_NODES=1
E: DM_MULTIPATH_DEVICE_PATH=1
E: ID_FS_TYPE=mpath_member
I found that multipathd configured by using mpathconf --find_multipaths greedy picks up the device without using multipath -a and in this case the udev information of the path is immediately correct (without a reboot). I would prefer to have a more fine-grained control over which devices are configured as multipath, though, and this behavior does not look correct.
When examining the difference between the two cases, I found that when using greedy multipathd emits a change event for /dev/sdd which then triggers the update of the udev variables and deletion of the partition device nodes, and this does not happen when using multipath -a and then restarting multipathd. (The rule that sets DM_MULTIPATH_DEVICE_PATH is in /usr/lib/udev/rules.d/62-multipath.rules .) I then found that using udevadm trigger -w -c change /dev/sdd after restarting multipathd corrects everything.
While it is nice to have a workaround, I believe that this is a bug and the event should have been emitted by multipathd itself, because a documented use of multipath and multipathd should not lead to a situation which is apparently inconsistent.
I looked into multipath-tools code and found two locations that are most likely related to the problem:
Not sure which of them is executed, but both seem to trigger udev on the paths only if the wwid gets newly added to the wwids file, which would explain the behavior (when using multipath -a the wwid is already there, with greedy it is not - multipathd adds it). If that's the case, what is the reason for this behavior?
This is on RHEL 8 and RHEL 9 btw (multipath tools version 0.8.4 and 0.8.7).
The text was updated successfully, but these errors were encountered:
@mwilck note that I have not mentioned any use of mpathconf in the problematic case (only in the working case). How is it relevant that mpathconf is not part of the upstream tools?
Usage of mpathconf is an indicator for someone not using standard procedures, at least from my personal point of view.
The expected behavior is that with find_multipaths greedy, your single-path device would be picked up by multipathd, like (almost) any other block device. "greedy" is best combined with some sort of blackisting. You could do something like this in multipath.conf:
I would like to configure multipath on a device which has only one path (
/dev/sdd
). (This is for testing, but I believe there may be uses for this even in production, e.g. when only one path exists for a device, but one knows that more paths will appear.)I tried to do this via adding the device to the wwids file (
multipath -a /dev/sdd
) and restarting multipathd (systemctl restart multipathd
), which then picks up the device and creates the multipath map (/dev/mapper/mpatha
). This mostly works, but I have encountered an irregularity whereudevadm info
on the path does not show that it is a path:Also, there are still partition device nodes on
/dev/sdd
(they should have been deleted by/usr/lib/udev/rules.d/68-del-part-nodes.rules
):This gets corrected after reboot,
udevadm info
shows the expected results:I found that multipathd configured by using
mpathconf --find_multipaths greedy
picks up the device without usingmultipath -a
and in this case the udev information of the path is immediately correct (without a reboot). I would prefer to have a more fine-grained control over which devices are configured as multipath, though, and this behavior does not look correct.When examining the difference between the two cases, I found that when using
greedy
multipathd emits a change event for/dev/sdd
which then triggers the update of the udev variables and deletion of the partition device nodes, and this does not happen when usingmultipath -a
and then restarting multipathd. (The rule that setsDM_MULTIPATH_DEVICE_PATH
is in/usr/lib/udev/rules.d/62-multipath.rules
.) I then found that usingudevadm trigger -w -c change /dev/sdd
after restarting multipathd corrects everything.While it is nice to have a workaround, I believe that this is a bug and the event should have been emitted by multipathd itself, because a documented use of
multipath
andmultipathd
should not lead to a situation which is apparently inconsistent.I looked into multipath-tools code and found two locations that are most likely related to the problem:
multipath-tools/libmultipath/configure.c
Line 940 in ee3a701
multipath-tools/multipathd/main.c
Line 3087 in ee3a701
Not sure which of them is executed, but both seem to trigger udev on the paths only if the wwid gets newly added to the wwids file, which would explain the behavior (when using
multipath -a
the wwid is already there, withgreedy
it is not - multipathd adds it). If that's the case, what is the reason for this behavior?This is on RHEL 8 and RHEL 9 btw (multipath tools version 0.8.4 and 0.8.7).
The text was updated successfully, but these errors were encountered: