On Wed, 2023-11-15 at 15:02 -0600, David Teigland wrote: > On Wed, Nov 15, 2023 at 09:51:19AM +0100, Peter Rajnoha wrote: > > > I've suggested another way to do that which could be more explicit, > and > gives more control over exactly what info is used for multipath, e.g. > > multipath_info_sources = [ "option1", "option2", "option3" ] > > where options in the list are used in order, and can reference any > number > of methods... udev, sysfs, wwids file, some new multipath lib, etc. Ugh. That adds even more complexity without improving matters. How would a user make a reasonable choice for such a setting? I think even you and I would have a hard time suggesting the "right" setting. Well, obviously my personal suggestion would be to use udev, and udev alone. :-) I guess it's too late now, but I'd still be willing to try and help sorting out the issues that you guys were having with udev's multipath component detection logic. > The context of using system.devices or not also makes a difference in > these choices, and I haven't thought through that entirely yet. > Perhaps > different defaults should apply when system.devices is in use (i.e. > that > multipath_info_sources list may want to depend on using > system.devices.) > > In principle, the multipath wwids option is an unfortunate, temporary > workaround we tried to avoid. Principles sometimes give way to real > world > problems like systems not booting. Ideally, a multipath lib API > would > have been available to check the wwids (which didn't involve udev.) There is libmpathvalid which was created for this purpose, have you tried it? AFAICT it should give the answers that udev would (Ben would know better though). Regards Martin
