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

[Peter Rajnoha]

On Mon 27 Sep 2021 10:38, David Teigland wrote:
> On Mon, Sep 27, 2021 at 12:00:32PM +0200, Peter Rajnoha wrote:
> > > - We could use the new lvm-activate-* services to replace the activation
> > > generator when lvm.conf event_activation=0.  This would be done by simply
> > > not creating the event-activation-on file when event_activation=0.
> > 
> > ...the issue I see here is around the systemd-udev-settle:
> 
> Thanks, I have a couple questions about the udev-settle to understand that
> better, although it seems we may not need it.
> 
> >   - the setup where lvm-activate-vgs*.service are always there (not
> >     generated only on event_activation=0 as it was before with the
> >     original lvm2-activation-*.service) practically means we always
> >     make a dependency on systemd-udev-settle.service, which we shouldn't
> >     do in case we have event_activation=1.
> 
> Why wouldn't the event_activation=1 case want a dependency on udev-settle?
> 

For event-based activation, I'd expect it to really behave in event-based
manner, that is, to respond to events as soon as they come and not wait
for all the other devices unnecessarily.

The use of udev-settle is always a pain - for example, if there's a mount
point defined on top of an LV, with udev-settle as dependency, we practically
wait for all devices to settle. With 'all', I mean even devices which are not
block devices and which are not event related to any of that LVM layout and
the stack underneath. So simply we could be waiting uselessly and we
could increase possibility of a timeout (...for the mount point etc.).

With the settle in play, we'd have this sequence/ordering with the
services/executions:

systemd-udev-settle.service --> lvm-activate-vgs-main.service -->
lvm-activate-vgs-last.service --> event-based pvscans

> >   - If we want to make sure that we run our "non-event-based activation"
> >     after systemd-udev-settle.service, we also need to use
> >     "After=systemd-udev-settle.service" (the "Wants" will only make the
> >     udev settle service executed, but it doesn't order it with respect
> >     to our activation services, so it can happen in parallel - we want
> >     it to happen after the udev settle).
> 
> So we may not fully benefit from settling unless we use After (although
> the benefits are uncertain as mentioned below.)
> 
> > Now the question is whether we really need the systemd-udev-settle at
> > all, even for that non-event-based lvm activation. The udev-settle is
> > just to make sure that all the udev processing and udev db content is
> > complete for all triggered devices. But if we're not reading udev db and
> > we're OK that those devices might be open in parallel to lvm activation
> > period (e.g. because there's blkid scan done on disks/PVs), we should be
> > OK even without that settle. However, we're reading some info from udev db,
> > right? (like the multipath component state etc.)
> 
> - Reading the udev db: with the default external_device_info_source=none
>   we no longer ask the udev db for any info about devs.  (We now follow
>   that setting strictly, and only ask udev when source=udev.)

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:

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

So what if someone defines an LVM regex filter that accepts only the
symlink name which is just to be created based on udev rules we're
processing right now?

(The nodes under /dev are OK because they're created in devtmpfs as
soon as the devices are created in kernel, but those symlinks in /dev
are always created by udev based on udev rules.)

> 
> - Concurrent blkid and activation: I can't find an issue with this
>   (couldn't force any interference with some quick tests.)
> 
> - I wonder if After=udev-settle could have an incidental but meaningful
>   effect of more PVs being in place before the service runs?
> 

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'll try dropping udev-settle in all cases to see how things look.
> 
> Dave
> 

-- 
Peter