On 11/14/23 17:30, David Teigland wrote: > On Tue, Nov 14, 2023 at 08:55:39AM +0100, Peter Rajnoha wrote: >> On 11/13/23 19:38, David Teigland wrote: >>> - In general, it's old versions of lvm that we're discussing here. >>> Current lvm uses system.devices by default, where none of this is >>> relevant. We can just turn off a number of filters when system.devices is >>> in use, including filter-mpath and filter-md. It may still be interesting >>> to look at improvements, but the context for that is older stable, >>> released versions. >> >> Hmm, but to generate or update the system.devices file and to add a new >> entry there, we still need to check first whether it's a suitable device >> or not, right? Like not being a multipath component... > > If they know what they're doing, a user won't add a multipath/md component > to system.devices (or other unusable devices.) However, it makes sense to > apply these checks when a device is added to system.devices to catch user > mistakes. Also for vgimportdevices -a where a specific device is not > named. The checks become a one-time thing, done when adding the device. > The checks are not needed by ordinary lvm commands, and are not being run > at tricky times like boot or for event handling. 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. -- Peter
