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

[Zdenek Kabelac <zkabelac@redhat.com>]

Dne 16. 11. 23 v 16:40 Martin Wilck napsal(a):
> 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.


Yep - it needs to be fully understood and supported by distro - so changing 
default may cause significant troubles - and took us quite some time to figure 
out various details in RHEL - and I think we still have few opened issues to 
solve. So even if we would flip default - configure process should be giving 
some major message notification about such change and how to easily 'switch' 
to previous 'fillter' logic.   So 'dstro' maintainer then just adds  configure 
option and keeps it in older state until distro gets ready for such changes.

Note - it's  somewhat easier to have the change present in the installation 
compared with  'upgrading' path with already existing  lvm.conf...

Zdenek