[linux-lvm] system boot time regression when using lvm2-2.03.05

[Martin Wilck]

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