Hi David, On Mon, 2019-09-09 at 09:09 -0500, David Teigland wrote: > On Mon, Sep 09, 2019 at 11:42:17AM +0000, Heming Zhao wrote: > > Hello David, > > > > You are right. Without calling _online_pvscan_one(), the pv/vg/lv > > won't be actived. > > The activation jobs will be done by systemd calling lvm2- > > activation-*.services later. > > > > Current code, the boot process is mainly blocked by: > > ``` > > _pvscan_aa > > vgchange_activate > > _activate_lvs_in_vg > > sync_local_dev_names > > fs_unlock > > dm_udev_wait <=== this point! > > ``` > > Thanks for debugging that. With so many devices, one possibility > that > comes to mind is this error you would probably have seen: > "Limit for the maximum number of semaphores reached" Could you explain to us what's happening in this code? IIUC, an incoming uevent triggers pvscan, which then possibly triggers VG activation. That in turn would create more uevents. The pvscan process then waits for uevents for the tree "root" of the activated LVs to be processed. Can't we move this waiting logic out of the uevent handling? It seems weird to me that a process that acts on a uevent waits for the completion of another, later uevent. This is almost guaranteed to cause delays during "uevent storms". Is it really necessary? Maybe we could create a separate service that would be responsible for waiting for all these outstanding udev cookies? Martin _______________________________________________ linux-lvm mailing list linux-lvm@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
