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

[Peter Rajnoha]

On Mon 07 Jun 2021 16:48, David Teigland wrote:
> On Mon, Jun 07, 2021 at 03:48:30PM +0000, Martin Wilck wrote:
> > On So, 2021-06-06 at 14:15 +0800, heming.zhao at suse.com wrote:
> > > 
> > > 1. During boot phase, lvm2 automatically swithes to direct activation
> > > mode
> > > ("event_activation = 0"). After booted, switch back to the event
> > > activation mode.
> > > 
> > > Booting phase is a speical stage. *During boot*, we could "pretend"
> > > that direct
> > > activation (event_activation=0) is set, and rely on lvm2-activation-
> > > *.service
> > > for PV detection. Once lvm2-activation-net.service has finished, we
> > > could
> > > "switch on" event activation.
> > 
> > I like this idea. Alternatively, we could discuss disabling event
> > activation only in the "coldplug" phase after switching root (i.e.
> > between start of systemd-udev-trigger.service and lvm2-
> > activation.service), because that's the critical time span during which
> > 1000s of events can happen simultaneously.
> 
> 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.

Peter