Re: LVM autoactivation and udev

David Teigland <[email protected]>
Newsgroups gmane.linux.lvm.general
Message-ID <[email protected]>
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
[email protected]
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.