On Wed, Sep 29, 2021 at 11:39:52PM +0200, Peter Rajnoha wrote:
> Hmm, thinking about this, I've just realized one more important and related
> thing here I didn't realize before - the LVM regex filters! These may contain
> symlink names as one can find them in /dev. But for those symlinks, we need
> to be sure that the rules are already applied. This practically means that:
At least at RH we're enabling the devices file by default (meaning no
filter) in the same timeframe that we're looking at these activation
services. So, I don't think this is a big factor.
> - For non-event-based activation, we need udev-settle (so we're sure
> all the rules are applied for all devices we might be scanning).
>
> - For event-based activation, we need to be sure that we use "RUN"
> rule, not any of "IMPORT{program}" or "PROGRAM" rule. The difference
> is that the "RUN" rules are applied after all the other udev rules are
> already applied for current uevent, including creation of symlinks. And
> currently, we have IMPORT{program}="pvscan..." in our rule,
> unfortunately...
That's pretty subtle, I'm wary about propagating such specific and
delicate behavior, seems fragile.
> The nodes are already there, the symlinks could be missing because the
> udev rules haven't been processed yet.
>
> Non-event-based LVM activation needs to wait for settle for sure (because
> there's full scan across all devices).
>
> Event-based LVM activation just needs to be sure that:
>
> - the pvscan only scans the single device (the one for which there's
> the uevent currently being processed),
>
> - the pvscan should be called in a way that we have all the symlinks
> in place so the regex filter still works for symlinks (== putting
> the pvscan onto a RUN exec queue).
I think we're looking at a udev-settle dependency (or alternative) for all
cases, best to just make that explicit and consistent, and isolated in one
place. I'm not really seeing a downside to that. Then, focus efforts on
refining a replacement. If the subtle dependencies are spread around then
it's hard to extract and improve the unwanted parts.
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/
