On Wed, 2021-09-29 at 23:39 +0200, Peter Rajnoha wrote: > On Mon 27 Sep 2021 10:38, 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? > > > > For event-based activation, I'd expect it to really behave in event- > based > manner, that is, to respond to events as soon as they come and not > wait > for all the other devices unnecessarily. I may be missing something here. Perhaps I misunderstood David's concept. Of course event-based activation is best - in theory. The reason we're having this discussion is that it may cause thousands of event handlers being executed in parallel, and that we have seen cases where this was causing the system to stall during boot for minutes, or even forever. The ideal solution for that would be to figure out how to avoid the contention, but I thought you and David had given up on that. Heming has shown that the "static" activation didn't suffer from this problem. So, to my understanding, David was seeking for a way to reconcile these two concepts, by starting out statically and switching to event-based activation when we can without the risk of stalling. To do that, we must figure out when to switch, and (like it or not) udev settle is the best indicator we have. Also IMO David was striving for a solution that "just works" efficiently both an small and big systems, without the admin having to adjust configuration files. > The use of udev-settle is always a pain - for example, if there's a > mount > point defined on top of an LV, with udev-settle as dependency, we > practically > wait for all devices to settle. With 'all', I mean even devices which > are not > block devices and which are not event related to any of that LVM > layout and > the stack underneath. So simply we could be waiting uselessly and we > could increase possibility of a timeout (...for the mount point > etc.). True, but is there anything better? > > Non-event-based LVM activation needs to wait for settle for sure > (because > there's full scan across all devices). > > Event-based LVM activation just needs to be sure that: > > - the pvscan only scans the single device (the one for which > there's > the uevent currently being processed), If that really worked without taking any locks (e.g. on the data structures about VGs), it would be the answer. Martin _______________________________________________ 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/
