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

[Peter Rajnoha <prajnoha@redhat.com>]

Hi!

the patches and logic looks promising, there's just one thing I'm
worried about...

On Thu 09 Sep 2021 14:44, David Teigland wrote:
> I've implemented a solution like this and would like any thoughts,
> improvements, or testing to verify it can help:
> https://sourceware.org/git/?p=lvm2.git;a=shortlog;h=refs/heads/dev-dct-activation-switch-1
> 
> I've taken some direction from the lvm activation generator, but there are
> details of that I'm not too familiar with, so I may be missing something
> (in particular it has three activation points but I'm showing two below.)
> This new method would probably let us drop the activation-generator, since
> we could easily configure an equivalent using this new method.
> 
> Here's how it works:
> 
> uevents for PVs run pvscan with the new option --eventactivation check.
> This makes pvscan check if the /run/lvm/event-activation-on file exists.
> If not, pvscan does nothing.
> 
> lvm-activate-vgs-main.service
> . always runs (not generated)
...
> lvm-activate-vgs-last.service
> . always runs (not generated)
...
> - 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:

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

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

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

-- 
Peter

_______________________________________________
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/