2021-03-26 19:39:05 +03:00
# Copyright (C) 2012,2021 Red Hat, Inc. All rights reserved.
#
# This file is part of LVM.
#
# This rule requires blkid to be called on block devices before so only devices
# used as LVM PVs are processed (ID_FS_TYPE="LVM2_member").
SUBSYSTEM!="block", GOTO="lvm_end"
(LVM_EXEC_RULE)
ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}=="1", GOTO="lvm_end"
# Only process devices already marked as a PV - this requires blkid to be called before.
ENV{ID_FS_TYPE}!="LVM2_member", GOTO="lvm_end"
ENV{DM_MULTIPATH_DEVICE_PATH}=="1", GOTO="lvm_end"
ACTION=="remove", GOTO="lvm_end"
# Create /dev/disk/by-id/lvm-pv-uuid-<PV_UUID> symlink for each PV
ENV{ID_FS_UUID_ENC}=="?*", SYMLINK+="disk/by-id/lvm-pv-uuid-$env{ID_FS_UUID_ENC}"
# If the PV is a special device listed below, scan only if the device is
# properly activated. These devices are not usable after an ADD event,
# but they require an extra setup and they are ready after a CHANGE event.
# Also support coldplugging with ADD event but only if the device is already
# properly activated.
# This logic should be eventually moved to rules where those particular
# devices are processed primarily (MD and loop).
# DM device:
KERNEL!="dm-[0-9]*", GOTO="next"
ENV{DM_UDEV_PRIMARY_SOURCE_FLAG}=="1", ENV{DM_ACTIVATION}=="1", GOTO="lvm_scan"
GOTO="lvm_end"
# MD device:
LABEL="next"
KERNEL!="md[0-9]*", GOTO="next"
IMPORT{db}="LVM_MD_PV_ACTIVATED"
ACTION=="add", ENV{LVM_MD_PV_ACTIVATED}=="1", GOTO="lvm_scan"
ACTION=="change", ENV{LVM_MD_PV_ACTIVATED}!="1", TEST=="md/array_state", ENV{LVM_MD_PV_ACTIVATED}="1", GOTO="lvm_scan"
ACTION=="add", KERNEL=="md[0-9]*p[0-9]*", GOTO="lvm_scan"
ENV{LVM_MD_PV_ACTIVATED}!="1", ENV{SYSTEMD_READY}="0"
GOTO="lvm_end"
# Loop device:
LABEL="next"
KERNEL!="loop[0-9]*", GOTO="next"
ACTION=="add", ENV{LVM_LOOP_PV_ACTIVATED}=="1", GOTO="lvm_scan"
ACTION=="change", ENV{LVM_LOOP_PV_ACTIVATED}!="1", TEST=="loop/backing_file", ENV{LVM_LOOP_PV_ACTIVATED}="1", GOTO="lvm_scan"
ENV{LVM_LOOP_PV_ACTIVATED}!="1", ENV{SYSTEMD_READY}="0"
GOTO="lvm_end"
LABEL="next"
ACTION!="add", GOTO="lvm_end"
LABEL="lvm_scan"
ENV{SYSTEMD_READY}="1"
# pvscan will check if this device completes a VG,
# i.e. all PVs in the VG are now present with the
# arrival of this PV. If so, it prints to stdout:
# LVM_VG_NAME_COMPLETE='foo'
#
# When the VG is complete it can be activated, so
# vgchange -aay <vgname> is run. It is run via
# systemd since it can take longer to run than
# udev wants to block when processing rules.
# (if there are hundreds of LVs to activate,
# the vgchange can take many seconds.)
#
# pvscan only reads the single device specified,
# and uses temp files under /run/lvm to check if
# other PVs in the VG are present.
#
# If event_activation=0 in lvm.conf, this pvscan
# (using checkcomplete) will do nothing, so that
# no event-based autoactivation will be happen.
#
# TODO: adjust the output of vgchange -aay so that
# it's better suited to appearing in the journal.
add activation services
New systemd services for startup:
lvm-devices-wait.service
Used in place of systemd-udev-settle, this service waits
for udev+pvscan to process PVs listed in system.devices.
It runs the command "lvmdevices --wait pvsonline".
This only waits for PVs that can be matched to a device in
sysfs, so it only waits for devices attached to the system.
It waits specifically for the /run/lvm/pvs_online/<pvid>
files to be created by pvscan. It quits waiting after a
configurable number of seconds. This service gives the
first activation service a chance to activate VGs from
PVs that are available immediately at startup. If this
service quits waiting before all the expected pvid files
appear, then the VG associated with those PVs will most
likely be activated by the -last service rather than the
initial -main service. If those PVs are even slower to
complete processing than the -last service, then the VG
will be activated by event activation whenever they are
finally complete.
lvm-activate-vgs-main.service
Calls "vgchange -aay", after lvm-devices-wait, to activate
complete VGs. It only considers PVs that have been
processed by udev+pvscan and have pvs_online files.
This is expected to activate VGs from basic devices
(not virtual device types) that are present at startup.
lvm-activate-vgs-last.service
Calls "vgchange -aay", after multipathd has started, to
activate VGs that became available after virtual device
services were started, e.g. VGs on multipath devices.
Like -main, it only looks at PVs that have been processed
by pvscan.
This vgchange in the -last service enables event activation
by creating the /run/lvm/event-activation-on file. Event
activation will activate any further VGs that appear on the
system (or complete udev processing) after the -last service.
In the case of event activation, the udev rule will run
vgchange -aay <vgname> via a transient service
lvm-activate-<vgname>.service. This vgchange only scans
PVs in the VG being activated, also based on the pvs_online
files from pvscan.
When there are many VGs that need activation during system
startup, the two fixed services can activate them all much
faster than activating each VG individually via events.
lvm.conf auto_activation_settings can be used to configure
the behavior (default ["service_and_event", "pvscan_hints"]).
"service_and_event" - the behavior described above, where
activation services are used first, and event activation
is used afterward.
"service_only" - only lvm-activate-vgs-* are used, and
no event-based activation occurs after the services finish.
(Equivalent to setting lvm.conf event_activation=0.)
"event_only" - the lvm-activate-vgs* services are skipped,
and all VGs are activated individually with event-based
activation.
"pvscan_hints" - the vgchange autoactivation commands
use pvs_online files created by pvscan. This optimization
limits the devices scanned by the vgchange command to only
PVs that have been processed by pvscan.
2021-09-02 23:15:46 +03:00
#
# "--autoactivation event" used with pvscan or vgchange
# tells the command that it is being run from an event.
2021-03-26 19:39:05 +03:00
add activation services
New systemd services for startup:
lvm-devices-wait.service
Used in place of systemd-udev-settle, this service waits
for udev+pvscan to process PVs listed in system.devices.
It runs the command "lvmdevices --wait pvsonline".
This only waits for PVs that can be matched to a device in
sysfs, so it only waits for devices attached to the system.
It waits specifically for the /run/lvm/pvs_online/<pvid>
files to be created by pvscan. It quits waiting after a
configurable number of seconds. This service gives the
first activation service a chance to activate VGs from
PVs that are available immediately at startup. If this
service quits waiting before all the expected pvid files
appear, then the VG associated with those PVs will most
likely be activated by the -last service rather than the
initial -main service. If those PVs are even slower to
complete processing than the -last service, then the VG
will be activated by event activation whenever they are
finally complete.
lvm-activate-vgs-main.service
Calls "vgchange -aay", after lvm-devices-wait, to activate
complete VGs. It only considers PVs that have been
processed by udev+pvscan and have pvs_online files.
This is expected to activate VGs from basic devices
(not virtual device types) that are present at startup.
lvm-activate-vgs-last.service
Calls "vgchange -aay", after multipathd has started, to
activate VGs that became available after virtual device
services were started, e.g. VGs on multipath devices.
Like -main, it only looks at PVs that have been processed
by pvscan.
This vgchange in the -last service enables event activation
by creating the /run/lvm/event-activation-on file. Event
activation will activate any further VGs that appear on the
system (or complete udev processing) after the -last service.
In the case of event activation, the udev rule will run
vgchange -aay <vgname> via a transient service
lvm-activate-<vgname>.service. This vgchange only scans
PVs in the VG being activated, also based on the pvs_online
files from pvscan.
When there are many VGs that need activation during system
startup, the two fixed services can activate them all much
faster than activating each VG individually via events.
lvm.conf auto_activation_settings can be used to configure
the behavior (default ["service_and_event", "pvscan_hints"]).
"service_and_event" - the behavior described above, where
activation services are used first, and event activation
is used afterward.
"service_only" - only lvm-activate-vgs-* are used, and
no event-based activation occurs after the services finish.
(Equivalent to setting lvm.conf event_activation=0.)
"event_only" - the lvm-activate-vgs* services are skipped,
and all VGs are activated individually with event-based
activation.
"pvscan_hints" - the vgchange autoactivation commands
use pvs_online files created by pvscan. This optimization
limits the devices scanned by the vgchange command to only
PVs that have been processed by pvscan.
2021-09-02 23:15:46 +03:00
IMPORT{program}="(LVM_EXEC)/lvm pvscan --cache --listvg --checkcomplete --vgonline --autoactivation event --udevoutput --journal=output $env{DEVNAME}"
ENV{LVM_VG_NAME_COMPLETE}=="?*", RUN+="/usr/bin/systemd-run -r --no-block --property DefaultDependencies=no --unit lvm-activate-$env{LVM_VG_NAME_COMPLETE} (LVM_EXEC)/lvm vgchange -aay --autoactivation event $env{LVM_VG_NAME_COMPLETE}"
2021-03-26 19:39:05 +03:00
GOTO="lvm_end"
LABEL="lvm_end"