[linux-lvm] Discussion: performance issue on event activation mode

David Teigland teigland at redhat.com
Tue Jun 8 15:39:37 UTC 2021

On Tue, Jun 08, 2021 at 08:26:01AM +0000, Martin Wilck wrote:
> IIUC, 2) is the effect of _pvscan_aa_quick(). 3) is surprising;
> apparently libudev's device detection causes a factor 3 slowdown.
> While 40s is not bad, you can see that event based activation still
> performs far worse than "serial" device detection lvm2-activation-
> early.service.
> Personally, I'm sort of wary about obtain_device_list_from_udev=0
> because I'm uncertain whether it might break multipath/MD detection.
> Perhaps you can clarify that.

Yes, that's an issue, but it's something we've needed to clean up for a
while, and I made a small start on it a while back.

obtain_device_list_from_udev is supposed to only control whether lvm gets
a list of device names from readdir /dev, or from libudev.  My preference
is default 0, readdir /dev.  This avoids the performance problem and makes
lvm less dependent on the vagaries of udev in general.

But, as you and Peter mentioned, obtain_device_list_from_udev also became
entangled with md/mpath detection methods, which is more closely related
to external_device_info_source=udev|none.

I think it would be an improvement to:

. Make obtain_device_list_from_udev only control how we get the device
  list. Then we can easily default to 0 and readdir /dev if it's better.

. Use both native md/mpath detection *and* udev info when it's readily
  available (don't wait for it), instead of limiting ourselves to one
  source of info.  If either source indicates an md/mpath component,
  then we consider it true.

The second point means we are free to change obtain_device_list_from_udev
as we wish, without affecting md/mpath detection.  It may also improve
md/mpath detection overall.

A third related improvement that could follow is to add stronger native
mpath detection, in which lvm uses uses /etc/multipath/wwids, directly or
through a multipath library, to identify mpath components.  This would
supplement the existing sysfs and udev sources, and address the difficult
case where the mpath device is not yet set up.


More information about the linux-lvm mailing list