On Wed, Mar 09, 2022 at 06:04:07PM +0100, Martin Wilck wrote:
> 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.
Having pvscan fork systemd-run vgchange -aay doesn't sound nice at all.
The point of this new design is clean up and simplify things, separating
the scanning from the activation: pvscan just scans the device, and
vgchange activates the VG.
> > 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 :-)
/etc/lvm/devices/system.devices lists the devices that lvm will use,
and lvm won't look at any other devices. More details in lvmdevices(8)
https://man7.org/linux/man-pages/man8/lvmdevices.8.html
> 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?
Right, lvm will never look at sda or sdb because they won't be listed in
system.devices.
> > - 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.
Yes, it's not perfect, but it may help in some cases, and there are
multiple methods that will usually exclude a component before this.
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/
