On Fr, 2021-07-02 at 16:09 -0500, David Teigland wrote: > On Sun, Jun 06, 2021 at 02:15:23PM +0800, heming.zhao@xxxxxxxx wrote: > > dev_cache_scan //order: O(n^2) > > + _insert_dirs //O(n) > > | if obtain_device_list_from_udev() true > > | _insert_udev_dir //O(n) > > | > > + dev_cache_index_devs //O(n) > > I've been running some experiments and trying some patches to improve > this. By setting obtain_device_list_from_udev=0, and using the > attached > patch to disable dev_cache_index_devs, the pvscan is much better. > > systemctl status lvm2-pvscan appears to show that the pvscan command > itself runs for only 2-4 seconds, while the service as a whole takes > around 15 seconds. See the 16 sec gap below from the end of pvscan > to the systemd Started message. If that's accurate, the remaining > delay > would lie outside lvm. > > Jul 02 15:27:57 localhost.localdomain systemd[1]: Starting LVM event > activation on device 253:1710... > Jul 02 15:28:00 localhost.localdomain lvm[65620]: pvscan[65620] PV > /dev/mapper/mpathalz online, VG 1ed02c7d-0019-43c4-91b5-f220f3521ba9 > is complete. > Jul 02 15:28:00 localhost.localdomain lvm[65620]: pvscan[65620] VG > 1ed02c7d-0019-43c4-91b5-f220f3521ba9 run autoactivation. > Jul 02 15:28:00 localhost.localdomain lvm[65620]: 1 logical > volume(s) in volume group "1ed02c7d-0019-43c4-91b5-f220f3521ba9" now > active Printing this message is really the last thing that pvscan does? > Jul 02 15:28:16 localhost.localdomain systemd[1]: Started LVM event > activation on device 253:1710. If systemd is very busy, it might take some time until it sees the completion of the unit. We may need to involve systemd experts. Anyway, what counts is the behavior if we have lots of parallel pvscan processes. Thanks, Martin _______________________________________________ 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/
