On Wed, Mar 09, 2022 at 04:29:27PM +0100, Martin Wilck wrote:
> Hi David, hi Peter,
>
> we have recently updated LVM2 on openSUSE Factory, and are using the
> autoactivation feature now. We also use
> 'external_device_info_source="udev"' by default, because according to
> our experience it is the only way to make LVM device detection work
> reliably with multipath devices.
>
> With these settings, we see lots of "Udev database has incomplete
> information about device ..." messages:
>
> > [ 12.377563] apollon systemd-udevd[810]: sda5: Processing device (SEQNUM=2787, ACTION=add)
> > [ 12.412723] apollon systemd-udevd[810]: sda5: /usr/lib/udev/rules.d/69-dm-lvm.rules:82 Importing properties from results of '/usr/sbin/lvm pvscan --cache --listvg --checkcomplete --vgonline --autoactivation event --udevoutput --journal=output /dev/sda5'
> > [ 12.412767] apollon systemd-udevd[810]: sda5: Starting '/usr/sbin/lvm pvscan --cache --listvg --checkcomplete --vgonline --autoactivation event --udevoutput --journal=output /dev/sda5'
> > [ 12.413041] apollon systemd-udevd[810]: Successfully forked off '(spawn)' as PID 882.
> > [ 12.419458] apollon lvm[882]: Udev database has incomplete information about device /dev/sda5.
>
> This is no surprise, because 69-dm-lvm.rules contains
>
> IMPORT{program}="/usr/sbin/lvm pvscan --cache --listvg --checkcomplete --vgonline --autoactivation event --udevoutput --journal=output $env{DEVNAME}"
> ENV{LVM_VG_NAME_COMPLETE}=="?*", RUN+="/usr/bin/systemd-run --no-block --property DefaultDependencies=no --unit lvm-activate-$env{LVM_VG_NAME_COMPLETE} (LVM_EXEC)/lvm vgchange -aay --autoactivation event $env{LVM_VG_NAME_COMPLETE}"
>
> These rules are executed by udev while it is processing an "add" event
> for a PV. At that time, the udev data base doesn't contain an entry for
> this PV yet, because the entry is added only after the uevent is fully
> processed.
Right, this pvscan needs to avoid getting info from udev, regardless of
what's set in lvm.conf. We don't use udev for external_device_info_source
here so I missed that and will add a fix.
> Shouldn't "pvscan" be run in a RUN+= statement instead? Obviously if we
> do this, the lvm-activate-$VG unit must be started in some other way
> (e.g. by calling systemd-run directly from pvscan).
IMPORT is needed to import LVM_VG_NAME_COMPLETE from the pvscan output
into the udev rule so we know which VG to activate.
> In the cases we have observed so far, the VGs were assembled correctly
> despite these warnings. We aren't certain if this was by luck only. In
> any case, the messages irritate users.
>
> Or are we getting this completely wrong, and the new autoactivation
> feature should not be used with external_device_info_source="udev" at
> all?
right
> If that's the case, how is multipath component detection supposed
> to work?
There are multiple ways that it's avoided, some apply in different
situations:
- 69-dm-lvm.rules will often not even be called on a multipath component
device because udev has already figured out it's a component (I'd need
some reminding about exactly when/how this happens.)
- if 69-dm-lvm.rules is called on a multipath component, that device will
not exist in the lvm devices file, so pvscan will ignore it.
- if 69-dm-lvm.rules is called on a multipath component, and there's no
devices file, then filter-mpath checking sysfs holder info will
often detect and ignore it.
- if all three of those don't catch it, then filter-mpath will also
check if the component wwid is listed in /etc/multipath/wwids and
ignore the device if it is.
If all four of those methods fail to exclude a multipath component, then
an LV could be activated using the component. While this isn't good, it
can be corrected by running lvchange --refresh. I'd like to get any
details of that happening to see if we can improve it.
Dave
_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
