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
