Re: [linux-lvm] LVM autoactivation and udev

[Martin Wilck <mwilck@suse.com>]

On Wed, 2022-03-09 at 10:27 -0600, David Teigland wrote:
> 
> 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.

I see. That has the (IMO strange) side effect that the "udev property"
LVM_VG_NAME_COMPLETE is set on just one of multiple PVs, and will
disappear when that PV receives another uevent.

If we started pvscan later, in RUN, and a VG became complete, instead
of printing the VG name to stdout, it could run the "systemd-run"
command for lvm-activate-${VG}, which is currently called in 69-dm-
lvm.rules, directly instead, by fork()ing and exec()ing "systemd-run".
That was what I meant. Just a thought, not sure if it really works.

> > 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.)

Right: the rules are skipped if ENV{DM_MULTIPATH_DEVICE_PATH}=="1",
which is fine.

> - 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.

I need some reminding about how the devices file works :-)


In the past (with the previous event activation scheme), we'd see
effects like this: Suppose we have a dm device dm-1 consisting of 2
SCSI devices sda, sdb. sda is processed by udev, and multipathd sets up
the dm device with just that one member. sdb is present in the system,
but not yet processed by udev and not present in the udev db, thus not
seen by multipathd either. When pvscan was run on the dm device (dm-1,
say), it scanned sysfs (where sdb was present) for other devices. sdb
had no "holders" yet, so pvscan with external_device_info_source="none"
would consider it, find "duplicate devices" dm-1 and sdb, and fail.

Am I understanding correctly that with the new scheme, the devices file
would prevent this from happening?

> - 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.

Off-topic: I have seen that, and I'm not particularly happy about it,
because the wwids file doesn't always represent multipathd's view of
the world. It depends on the find_multipaths setting in multipath.conf.
Only if it's set to "strict" (the RHEL default) you can be sure that a
device that isn't in the wwids file will not be grabbed by multipathd
later.

Regards
Martin

_______________________________________________
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/