Re: [linux-lvm] Discussion: performance issue on event activation mode

[David Teigland <teigland@redhat.com>]

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@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/