Re: Discussion: performance issue on event activation mode

On Thu, 2021-09-09 at 14:44 -0500, David Teigland wrote:
> On Tue, Jun 08, 2021 at 01:23:33PM +0000, Martin Wilck wrote:
> > On Di, 2021-06-08 at 14:29 +0200, Peter Rajnoha wrote:
> > > On Mon 07 Jun 2021 16:48, David Teigland wrote:
> > > > 
> > > > If there are say 1000 PVs already present on the system, there
> > > > could be
> > > > real savings in having one lvm command process all 1000, and
> > > > then
> > > > switch
> > > > over to processing uevents for any further devices afterward. 
> > > > The
> > > > switch
> > > > over would be delicate because of the obvious races involved
> > > > with
> > > > new devs
> > > > appearing, but probably feasible.
> > > 
> > > Maybe to avoid the race, we could possibly write the proposed
> > > "/run/lvm2/boot-finished" right before we initiate scanning in
> > > "vgchange
> > > -aay" that is a part of the lvm2-activation-net.service (the last
> > > service to do the direct activation).
> > > 
> > > A few event-based pvscans could fire during the window between
> > > "scan initiated phase" in lvm2-activation-net.service's
> > > "ExecStart=vgchange -aay..."
> > > and the originally proposed "ExecStartPost=/bin/touch
> > > /run/lvm2/boot-
> > > finished",
> > > but I think still better than missing important uevents
> > > completely in
> > > this window.
> > 
> > That sounds reasonable. I was thinking along similar lines. Note
> > that
> > in the case where we had problems lately, all actual activation
> > (and
> > slowness) happened in lvm2-activation-early.service.
> 
> 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)
> . does not wait for other virtual block device systems to start
> . runs vgchange -aay to activate any VGs already present
> 
> lvm-activate-vgs-last.service
> . always runs (not generated)
> . runs after other systems, like multipathd, have started (we want it
>   to find as many VGs to activate as possible)
> . runs vgchange -aay --eventactivation enable
> . the --eventactivation enable creates /run/lvm/event-activation-on,
>   which enables the traditional pvscan activations from uevents.
> . this vgchange also creates pv online files for existing PVs.
>   (Future pvscans will need the online files to know when VGs are
>   completed, i.e. for VGs that are partially complete at the point
>   of switching to event based actvivation.)
> 
> uevents for PVs continue to run pvscan with the new option
> --eventactivation check, but the check now sees the event-activation-
> on
> temp file, so they will do activation as they have before.
> 
> Notes:
> 
> - To avoid missing VGs during the transition to event-based, the
> vgchange
> in lvm-activate-vgs-last will create event-activation-on before doing
> anything else.  This means for a period of time both vgchange and
> pvscan
> may attempt to activate the same VG.  These commits use the existing
> mechanism to resolve this (the --vgonline option and
> /run/lvm/vgs_online).
> 
> - 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.
> 
> - To do the reverse, and use only event based activation without any
> lvm-activate-vgs services, a new lvm.conf setting could be used, e.g.
> event_activation_switch=0 and disabling lvm-activate-vgs services.

This last idea sounds awkward to me. But the rest is very nice. 
Heming, do you agree we should give it a try?

Thanks,
Martin


_______________________________________________
linux-lvm mailing list
[email protected]
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/