|
 |
fabacb |
From 7631c5b826b5a3eddfcd22db9b80574b249794c1 Mon Sep 17 00:00:00 2001
|
|
|
fabacb |
From: David Teigland <teigland@redhat.com>
|
|
|
fabacb |
Date: Mon, 6 Dec 2021 13:20:32 -0600
|
|
|
fabacb |
Subject: [PATCH 21/23] man: add section about static autoactivation
|
|
|
fabacb |
|
|
|
fabacb |
---
|
|
|
fabacb |
man/lvmautoactivation.7_main | 48 ++++++++++++++++++++++++++++++------
|
|
|
fabacb |
1 file changed, 41 insertions(+), 7 deletions(-)
|
|
|
fabacb |
|
|
|
fabacb |
diff --git a/man/lvmautoactivation.7_main b/man/lvmautoactivation.7_main
|
|
|
fabacb |
index 87c15a3d1..bf885991d 100644
|
|
|
fabacb |
--- a/man/lvmautoactivation.7_main
|
|
|
fabacb |
+++ b/man/lvmautoactivation.7_main
|
|
|
fabacb |
@@ -14,14 +14,16 @@ activated.
|
|
|
fabacb |
Autoactivation of VGs, or specific LVs, can be prevented using vgchange or
|
|
|
fabacb |
lvchange --setautoactivation n. The lvm.conf auto_activation_volume_list
|
|
|
fabacb |
is another way to limit autoactivation.
|
|
|
fabacb |
+.
|
|
|
fabacb |
+.SS event autoactivation
|
|
|
fabacb |
.P
|
|
|
fabacb |
The most common form of autoactivation is "event based", in which complete
|
|
|
fabacb |
VGs are activated in response to uevents which occur during system startup
|
|
|
fabacb |
or at any time after the system has started. Another form of
|
|
|
fabacb |
-autoactivation is "service based" in which complete VGs are activated at a
|
|
|
fabacb |
-fixed point during system startup by a systemd service, and are not
|
|
|
fabacb |
-activated in response to uevents. This can be controlled with the
|
|
|
fabacb |
-lvm.conf setting event_activation.
|
|
|
fabacb |
+autoactivation is "static" in which complete VGs are activated at a fixed
|
|
|
fabacb |
+point during system startup by a systemd service, and not in response to
|
|
|
fabacb |
+events. This can be controlled with the lvm.conf setting
|
|
|
fabacb |
+event_activation.
|
|
|
fabacb |
.P
|
|
|
fabacb |
Event based autoactivation is driven by udev, udev rules, and systemd.
|
|
|
fabacb |
When a device is attached to a machine, a uevent is generated by the
|
|
|
fabacb |
@@ -30,8 +32,8 @@ rules to process the new device. Udev rules use blkid to identify the
|
|
|
fabacb |
device as an LVM PV and then execute the lvm-specific udev rule for the
|
|
|
fabacb |
device, which triggers autoactivation.
|
|
|
fabacb |
.P
|
|
|
fabacb |
-There are two variations of event based autoactivation that may be used a
|
|
|
fabacb |
-system, depending on the LVM udev rule that is installed (found in
|
|
|
fabacb |
+There are two variations of event baed autoactivation that may be used on
|
|
|
fabacb |
+a system, depending on the LVM udev rule that is installed (found in
|
|
|
fabacb |
/lib/udev/rules.d/.) The following summarizes the steps in each rule
|
|
|
fabacb |
which lead to autoactivation:
|
|
|
fabacb |
.P
|
|
|
fabacb |
@@ -149,7 +151,7 @@ using the udev environment key format, i.e. NAME='value'.
|
|
|
fabacb |
Send standard command output to the journal (when stdout
|
|
|
fabacb |
is reserved for udev output.)
|
|
|
fabacb |
.P
|
|
|
fabacb |
-.SS Temp files
|
|
|
fabacb |
+.SS run files
|
|
|
fabacb |
.P
|
|
|
fabacb |
Autoactivation commands use a number of temp files in /run/lvm (with the
|
|
|
fabacb |
expectation that /run is cleared between boots.)
|
|
|
fabacb |
@@ -175,6 +177,38 @@ The first activation command (pvscan or vgchange) to create a file here,
|
|
|
fabacb |
named for the VG, will activate the VG. This resolves a race when
|
|
|
fabacb |
concurrent commands attempt to activate a VG at once.
|
|
|
fabacb |
.
|
|
|
fabacb |
+.SS static autoactivation
|
|
|
fabacb |
+.P
|
|
|
fabacb |
+When event autoactivation is disabled by setting lvm.conf
|
|
|
fabacb |
+event_activation=0, autoactivation is performed at one or more static
|
|
|
fabacb |
+points during system startup. At these points, a vgchange -aay command is
|
|
|
fabacb |
+run to activate complete VGs from devices that are present on the system
|
|
|
fabacb |
+at that time. pvscan commands (and lvm2-pvscan services) do not perform
|
|
|
fabacb |
+autoactivation in this mode. pvscan commands may still be run from
|
|
|
fabacb |
+uevents but will do nothing when they read the event_activation=0 setting.
|
|
|
fabacb |
+.P
|
|
|
fabacb |
+The static vgchange -aay commands are run by three systemd services at
|
|
|
fabacb |
+three points during startup: lvm2-activation-early, lvm2-activation, and
|
|
|
fabacb |
+lvm2-activation-net. These static activation services are "generated
|
|
|
fabacb |
+services", so the service files are created at run time by the
|
|
|
fabacb |
+lvm2-activation-generator command (run by systemd).
|
|
|
fabacb |
+lvm2-activation-generator creates the services if lvm.conf
|
|
|
fabacb |
+event_activation=0.
|
|
|
fabacb |
+.P
|
|
|
fabacb |
+The limitation of this method is that devices may not be attached to the
|
|
|
fabacb |
+system (or set up) at a reliable point in time during startup, and they
|
|
|
fabacb |
+may not be present when the services run vgchange. In this case, the VGs
|
|
|
fabacb |
+will not be autoactivated. So, the timing of device attachment/setup
|
|
|
fabacb |
+determines whether static autoactivation will produce the same results as
|
|
|
fabacb |
+event autoactivation. For this reason, static autoactivation is not
|
|
|
fabacb |
+recommended.
|
|
|
fabacb |
+.P
|
|
|
fabacb |
+Sometimes, static autoactivation is mistakenly expected to disable all
|
|
|
fabacb |
+autoactivation of particular VGs. This may appear to be effective if those
|
|
|
fabacb |
+VGs are slow to be attached or set up. But, the only correct and reliable
|
|
|
fabacb |
+way to disable autoactivation is using vgchange/lvchange
|
|
|
fabacb |
+--setautoactivation n, or lvm.conf auto_activation_volume_list.
|
|
|
fabacb |
+.
|
|
|
fabacb |
.SH EXAMPLES
|
|
|
fabacb |
.P
|
|
|
fabacb |
VG "vg" contains two PVs:
|
|
|
fabacb |
--
|
|
|
fabacb |
2.31.1
|
|
|
fabacb |
|