Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

multipathd does not trigger udev rules for a path that the user has added to the wwids file #103

Open
pcahyna opened this issue Nov 11, 2024 · 3 comments

Comments

@pcahyna
Copy link

pcahyna commented Nov 11, 2024

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:

(remember_wwid(mpp->wwid) == 1 ||

if (remember_wwid(mpp->wwid) == 1)

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).

@mwilck
Copy link
Contributor

mwilck commented Nov 12, 2024

The classification of paths between multipath-and non-multipath depends on the find_multipaths setting.

Note that mpathconf is Fedora/RedHat specific and not part of upstream multipath tools. Please report to your distribution.

(But maybe we can short-cut your issue by having @bmarzins comment here).

@pcahyna
Copy link
Author

pcahyna commented Nov 12, 2024

@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?

@mwilck
Copy link
Contributor

mwilck commented Nov 12, 2024

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:

blacklist {
    devnode .*
}
blacklist_exceptions {
    devnode sdd
}

(just a very crude example, we usually discourage blacklisting by devnode).

Without "greedy", you need to add it to the WWIDs file as you figured out yourself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants