Re: Discussion: performance issue on event activation mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Dave

_______________________________________________
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/




[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux