Re: Discussion: performance issue on event activation mode

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

 



Dne 15. 06. 21 v 19:03 David Teigland napsal(a):
On Tue, Jun 08, 2021 at 10:39:37AM -0500, David Teigland wrote:
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.

Here are the initial patches I'm testing (libmpathvalid not yet added)
https://sourceware.org/git/?p=lvm2.git;a=shortlog;h=refs/heads/dev-dct-device-info-1

devices: rework native and udev device info

. Make the obtain_device_list_from_udev setting
   affect only the choice of readdir /dev vs libudev
   for a device name listing.  The setting no longer
   controls if udev is used for device type checks.



While in the local testing it may appear devices on laptops are always fast,
in some cases it may actually be more expensive to check physical
device instead on checking content of udev DB.

So for some users this may result in performance regression as
udevDB is in ramdisk - while there are device where it's opening
may take seconds depending on operating status (disk suspend,
disk firmware upgrade....)

(one of lvmetad aspects should have been to avoid waking suspended device)

. Change obtain_device_list_from_udev default to 0.
   A list of device names is obtained from readdir /dev
   by default, which is faster than libudev (especially
   with many devices.)

So we need at least backward compatible setting for those users
where the performance impact would cause regression.


Zdenek

_______________________________________________
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