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

[David Teigland]

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?

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

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

I'll try dropping udev-settle in all cases to see how things look.

Dave