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@.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@.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
_______________________________________________
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/
