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

Zdenek Kabelac zkabelac at redhat.com
Tue Jun 15 18:21:32 UTC 2021


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




More information about the linux-lvm mailing list