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

[heming.zhao at suse.com]

On 6/10/21 2:59 AM, David Teigland wrote:
> On Wed, Jun 09, 2021 at 05:37:47AM +0000, Heming Zhao wrote:
>> This mail I will mention another issue about lvm2-pvscan at .service.
>> both event activation and direct activation have same issue:
>> the shutdown take much time.
>>
>> the code logic in pvscan_cache_cmd() only takes effect on activation job:
>> ```
>>      if (do_activate &&
>>          !find_config_tree_bool(cmd, global_event_activation_CFG, NULL)) {
>>          log_verbose("Ignoring pvscan --cache -aay because event_activation is disabled.");
>>          return ECMD_PROCESSED;
>>      }
>> ```
> 
> Good point, event_activation=0 should also apply to pvscan on device
> removal.
> 
>> and I have a question about the script  lvm2-pvscan at .service:
>> why there also does a scan job when stopping? could we remove/modify this line?
>>    ```
>>    ExecStop=@SBINDIR@/lvm pvscan --cache %i
>>    ```
> 
> This removes the /run/lvm/pvs_online/ file for the device.  If the PVs for
> the VG are all removed, and then they are all reattached, pvscan will
> autoactivate the VG again.  This reactivation isn't a core capability, or
> one that we've explicitly mentioned or supported, but it's there.  I can
> imagine that reactivation may be undesirable in many cases, and it's
> certainly reasonable to remove the ExecStop as needed.  Some time ago I
> suggested that we stop doing repeated autoactivation entirely, which would
> let us remove the ExecStop.  But we don't know the extent to which users
> depend on this behavior, so we haven't considered it further.  Perhaps
> pvscan could detect system shutdown and exit directly without doing
> anything?
> 
> For the future, the new udev rule I mentioned in an earlier message no
> longer does this and removes the lvm2-pvscan service.
> 
> Dave
> 

Thank you for your explaination. I am reading your code in dev-next branch.

Heming