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