Re: [linux-lvm] LVM autoactivation and udev

[David Teigland <teigland@redhat.com>]

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@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/