On Tue, 2023-11-21 at 11:56 -0600, David Teigland wrote:
> > PS: Here's a related remark about 17a3585 ("pvscan: use alternate
> > device names from DEVLINKS to check filter"). I can see why this
> > was
> > necessary, but I don't understand why this is found to be necessary
> > _now_; the same issue should have always existed if "pvscan" is
> > running
> > during a "change" event for any given device. The solution of
> > 17a3585
> > "worked" for us, but it looks only semi-ok to me. Other udev rules
> > may
> > modify the DEVLINKS list after pvscan had been running. A correct
> > solution must make sure that pvscan runs after all udev rules. IOW,
> > pvscan should be triggered in a udev RUN= statement rather then
> > IMPORT=. This would probably require a new systemd service, because
> > it's not just "pvscan" alone. But the result would be more robust
> > then what we currently have.
>
> To be sure we're talking about the same new udev rule, the context is
> 69-dm-lvm.rules, which does IMPORT from:
>
> pvscan --cache --listvg --checkcomplete --vgonline \
> --autoactivation event --udevoutput --journal=output
> /dev/foo
>
> That pvscan prints LVM_VG_NAME_COMPLETE='vgname', which is then
> passed to
> the actual activation command, executed through systemd-run:
>
> vgchange -aay --autoactivation event $LVM_VG_NAME_COMPLETE
>
> In our environments, this new autoactivation method coincides with
> default
> system.devices. So, we don't usually see this autoactivation method
> combined with the regex filter, and commit 17a3585 doesn't come into
> play.
> However, when the devices file is disabled and users have regex
> filters
> containing /dev/disk/ symlinks, then commit 17a3585 is necessary.
> (Avoiding this difficulty is another advantage of system.devices.)
>
> As for the udev rule specifics, the RUN vs IMPORT discussion occured
> previously here:
> https://listman.redhat.com/archives/linux-lvm/2021-October/026001.html
>
> The answer was that RUN doesn't allow pvscan to provide vgname
> (LVM_VG_NAME_COMPLETE) to vgchange.
Thanks for digging this up. You're of course right, passing this
environment variable back into the udev rule is impossible, given that
RUN is executed after the udev rule processing has finished.
But I wonder if this is required. You could create a script that
calls pvscan, and then systemd-run / vgchange with the output of the
pvscan command, and execute this script in RUN. That was roughly my
idea. That way you wouldn't loose any DEVLINKS added after 69-dm-
lvm.rules.
Thanks
Martin
