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

[Martin Wilck <martin.wilck@suse.com>]

On Thu, 2023-11-16 at 09:10 -0600, David Teigland wrote:
> On Thu, Nov 16, 2023 at 02:37:13PM +0100, Zdenek Kabelac wrote:
> > > and restore define DEFAULT_USE_DEVICES_FILE 1.
> > 
> > There is no problem with configuring DEFAULT_USE_DEVICES_FILE with
> > 'configure --with-default-use-devices-file= 0/1' and thus no need
> > to change
> > anything here.
> > 
> > Current upstream has set this default value as 0  (in configure.ac)
> 
> I didn't realize you'd changed the default, please set it back to 1.
> (Even better put back DEFAULT_USE_DEVICES_FILE; configured settings
> are a pain to deal with, and the complexity causes real problems.)

The problem I see with using system.devices by default is that it
requires installer support, as discussed previously. pvcreate will
create the file if it doesn't find existing VGs or PVs, which means
that the way LVM behaves depends on the system's history:

- If it was updated from an earlier LVM version, VGs are likely to
exist, and system.devices will not be created.
- If VGs were created by the installer without copying system.devices
into the installed system, system.device won't be created, either.
- If the users installs without LVM and uses pvcreate later on, LVM
will create system.devices, and switch to system.devices mode
- Not sure what happens if the system is running in "legacy" filtering
/ multipath component detection mode and something goes wrong during
boot, causing the PVs and VGs not to show up. If pvcreate is run in a
situation like that, would it also create system.devices and switch
modes?

Distributions can of of course flip the default, but unless I'm
mistaken RHEL9 (and possibly Fedora) are the only distros that fully
support system.devices mode just yet. Thus I vote for leaving it off by
default just now.

Regards
Martin