On Tue, Nov 14, 2023 at 05:48:45PM +0000, Martin Wilck wrote: > "If the system devices file does not yet exist, the pvcreate or > vgcreate commands will create it if they see no existing VGs on > the system." > > That basically means that every new installation (where PVs and VGs > will usually have to be created first) will use system.devices, and > thus disable use of filtering and traditional-style multipath component > detection. Right? Yes, a new install with no visible, existing VGs would run pvcreate or vgcreate which would create a new system.devices. That means the regex filter is disabled, and multipath component detection is unnecessary (we'd still check when a user adds a new device to system.devices to verify they aren't doing something dumb.) The installer should probably decide ahead of time how it wants lvm to look in the end, and then make that happen, rather than relying on lvm to adapt to the installer environment. In the case of anaconda, they set up new PVs without using system.devices, then at the end it runs "vgimportdevices -a" to create a new system.devices from the PVs it created, plus any others that are attached to the system when the installer is running. (We've had problems with not planning ahead sufficiently when it comes to OS images where the "install" doesn't happen on the actual system.) The sentence you quoted is not mainly about installation, but rather that lvm needs to have some kind of defined behavior for itself that's independent of an installer. > AFAICS the other use case is MD RAID, no? I think that LVM could rely > on udev for that as well. Right, I don't think we'd risk relying only on udev to detect that when AFAIK we've always included native detection to some degree. The consequences of using a raid image directly can be a bigger problem. The other case is detecting if a disk is partitioned (so we can ignore the whole disk.) > > This means adding another config > > option... not much different from just using multipath_wwids_file="". > > For multipath, external_device_info_source=udev used to mean "udev > only" until recently, unless I'm mistaken. Yes, although the default external_device_info_source has always been "none"... complicated by the fact that at various points in time some parts of lvm made ad hoc calls to check the udev state regardless of the none|udev value... it was a mess until I overhauled it all, the settings were not entirely followed, and it was not possible to control entirely. > The semantics of this settings has changed. I don't know what the > situation was for MD or possible other subsystems. I'm fine with calling > the algorithm "udev" if the respective semantics are still the same that > used to be called "udev" in the past. Hm, that past was not as ideal as you imagine, there is no coherent behavior to restore. There is the option I offered of a new setting that means exactly what you need: use only udev for detecting multipath components. > > Yes, it just causes lvm to skip the use of /etc/multipath/wwids for > > checking if a device is a multipath component. > > Thanks. I'm still not happy about it, but if we find no other solution, > I guess it will be ok. Could you try multipath_wwids_file="" and see if that's sufficient before we add a new setting that's nearly the same? Thanks, Dave
