Re: discuss about commit 3b0f9ce: filter-mpath: get wwids from sysfs vpd_pg83

[David Teigland <teigland@redhat.com>]

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