Hi! the patches and logic looks promising, there's just one thing I'm worried about... On Thu 09 Sep 2021 14:44, David Teigland wrote: > 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) ... > lvm-activate-vgs-last.service > . always runs (not generated) ... > - 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: - 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. - If we want to make sure that we run our "non-event-based activation" after systemd-udev-settle.service, we also need to use "After=systemd-udev-settle.service" (the "Wants" will only make the udev settle service executed, but it doesn't order it with respect to our activation services, so it can happen in parallel - we want it to happen after the udev settle). Now the question is whether we really need the systemd-udev-settle at all, even for that non-event-based lvm activation. The udev-settle is just to make sure that all the udev processing and udev db content is complete for all triggered devices. But if we're not reading udev db and we're OK that those devices might be open in parallel to lvm activation period (e.g. because there's blkid scan done on disks/PVs), we should be OK even without that settle. However, we're reading some info from udev db, right? (like the multipath component state etc.) -- 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/
