On Tue 28 Sep 2021 06:34, Martin Wilck wrote: > Hello David and Peter, > > On Mon, 2021-09-27 at 10:38 -0500, David Teigland wrote: > > On Mon, Sep 27, 2021 at 12:00:32PM +0200, Peter Rajnoha wrote: > > > > - 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: > > > > Thanks, I have a couple questions about the udev-settle to understand > > that > > better, although it seems we may not need it. > > > > > - 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. > > > > Why wouldn't the event_activation=1 case want a dependency on udev- > > settle? > > You said it should wait for multipathd, which in turn waits for udev > settle. And indeed it makes some sense. After all: the idea was to > avoid locking issues or general resource starvation during uevent > storms, which typically occur in the coldplug phase, and for which the > completion of "udev settle" is the best available indicator. > Udevd already limits the number of concurent worker processes processing the udev rules for each uevent. So even if we trigger all the uevents, they are not processed all in parallel, there's some queueing. However, whether this is good or not depends on perspective - you could have massive paralelism and a risk of resource starvation or, from the other side, you could have timeouts because something wasn't processed in time for other parts of the system which are waiting for dependencies. Also, the situation might differ based on the fact whether during the uevent processing we're only looking at that concrete single device for which we've just received an event or whether we also need to look at other devices. -- 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/
