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

[Heming Zhao <heming.zhao@suse.com>]

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!
```

For fix this boot time regression, it looks lvm2 should have a config item in lvm2.conf
i.e.: large_PV_boot_speedup.
When this item is 1, pvcan won't call _online_pvscan_one, then let lvm2-activation*.service
do the active jobs.
Is it a workable solution?

Thanks

On 9/6/19 10:03 PM, David Teigland wrote:
> On Fri, Sep 06, 2019 at 08:51:47AM +0200, Martin Wilck wrote:
>> IIUC this would mean that you skip David's "pvs_online" file generation
>> entirely. How did the auto-activation happen, then?
> 
> I'd like to know which services/commands are activating the LVs.  In the
> slow case it was clearly done by the lvm2-pvscan services, but in the fast
> case it looked like it was not.
> 
>> Could it be that lvm2-activation-net.service activated the VGs?  I can
>> imagine that that would be efficient, because when this service runs
>> late in the boot process, I'd expect all PVs to be online, so
>> everything can be activated in a single big swoop. Unfortunately, this
>> wouldn't work in general, as it would be too late for booting from LVM
>> volumes.
>>
>> However I thought all lvm2-acticvation... services were gone with LVM
>> 2.03?
> 
> They still exist.  In lvm 2.03, the lvm.conf event_activation setting
> controls whether activation is event-based via lvm2-pvscan services, or
> done by lvm2-activation services at fixed points during startup.  LVM
> commands in initramfs could also be interfering and activating more than
> the root LV.
> 
>