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