On Wed, Nov 15, 2023 at 09:51:19AM +0100, Peter Rajnoha wrote: > Sure, if we already have that in the devices file, we don't need to > rerun the filters again and again. But I think that for the very first > check we do when inserting new entry to the devices file, we should > really be using information that is *shared* by the other subsystem that > owns it. In case of multipath, we shouldn't be reading any of their > config or trying to reimplement subset of their logic (the config can > change format, the logic can change, new features can be added, various > settings can be applied which we omit in our own internal simplified > version of the logic). > > If I would need to compare the situation to something, imagine that some > subsystem, MD for example, would be parsing our system.devices file to > check if it can or can not access certain device. Then checking > multipath config, then other config and so on... So that way we would > have each subsystem checking other subsystems by reimplementing these > checks again and again (with the risk of not even being correct). > > We should be using dedicated APIs or udev to share the information among > various subsystems. Or, if nothing else, even calling out to the > subsystem's binary if it doesn't provide the API yet. > > I don't see an issue with the devices file as such, I see the issue in > the way we gather information, reimplementing the logic that is simply > not in our domain. > > I think that's also what Martin and Heming have in mind. I'm not sure if you're talking about things in practice or in principle. This is a situation where those two don't entirely line up. In practice, you can already do what's requested with: external_device_info_source="udev" multipath_wwid_files="" 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. 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 are a couple threads from 2021 about that, initially in https://listman.redhat.com/archives/lvm-devel/2021-January/022915.html I didn't have a complete understanding of the mess we were in during that thread, but it prompted me to begin sorting it all out. I think it's sane now, but fine-grained control over what info is used where could be added. And, system.devices may now let us make some different choices. Dave
