On Thu 30 Sep 2021 10:55, David Teigland wrote:
> On Wed, Sep 29, 2021 at 11:39:52PM +0200, Peter Rajnoha wrote:
> > Hmm, thinking about this, I've just realized one more important and related
> > thing here I didn't realize before - the LVM regex filters! These may contain
> > symlink names as one can find them in /dev. But for those symlinks, we need
> > to be sure that the rules are already applied. This practically means that:
>
> At least at RH we're enabling the devices file by default (meaning no
> filter) in the same timeframe that we're looking at these activation
> services. So, I don't think this is a big factor.
>
OK, if we don't need access to all the aliases (all the symlink names under /dev),
then that's great. We just need to make sure the devices file is then
always used with pvscan called out of the udev rule.
> > - For non-event-based activation, we need udev-settle (so we're sure
> > all the rules are applied for all devices we might be scanning).
> >
> > - For event-based activation, we need to be sure that we use "RUN"
> > rule, not any of "IMPORT{program}" or "PROGRAM" rule. The difference
> > is that the "RUN" rules are applied after all the other udev rules are
> > already applied for current uevent, including creation of symlinks. And
> > currently, we have IMPORT{program}="pvscan..." in our rule,
> > unfortunately...
>
> That's pretty subtle, I'm wary about propagating such specific and
> delicate behavior, seems fragile.
>
Yeah, that was just because I didn't realize we don't actually need those
symlinks and the classic filter is ignored in this case. I thought we
had a bug in our current 69-dm-lvm.rules where we call IMPORT{progra}=pvscan
in which case all the symlinks are not created yet. I'm glad it's not
the case.
> > The nodes are already there, the symlinks could be missing because the
> > udev rules haven't been processed yet.
> >
> > 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),
> >
> > - the pvscan should be called in a way that we have all the symlinks
> > in place so the regex filter still works for symlinks (== putting
> > the pvscan onto a RUN exec queue).
>
> I think we're looking at a udev-settle dependency (or alternative) for all
> cases, best to just make that explicit and consistent, and isolated in one
> place. I'm not really seeing a downside to that. Then, focus efforts on
> refining a replacement. If the subtle dependencies are spread around then
> it's hard to extract and improve the unwanted parts.
So then we can concentrate on minimizing the set of devices we need to
"settle". Right now, I don't see technical obstacles to implementing this,
but the separation of systemd-udev-settle.service into pieces would be a
first step for this to perform better, I think.
The only problematic part here might be systemd/udev's aversion to
anything having "udev-settle" in mind. But I think if we're able to show
them the difference and advantage of using the settle here by presenting
real numbers and analysis, there might be a chance. The separation of
udev-settle into pieces would surely help too, because we could isolate
the settle to devices we're only interested in.
We can surely discuss that with them. Would be great if we find consensus
here on all sides, I don't want to fight with or completely ignore
systemd/udev guys and their optinions...
--
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/
