Re: Discussion: performance issue on event activation mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx 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

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




[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux