mirror of
git://sourceware.org/git/lvm2.git
synced 2024-12-23 21:35:29 +03:00
1650c10438
We've been assigning this in 69-dm-lvm-metad.rules:
ENV{ID_MODEL}="LVM PV $env{ID_FS_UUID_ENC} on /dev/$name"
This was for the description to appear for each systemd device
unit representing this device, for example:
$systemctl -a | grep "LVM PV"
dev-block-252:2.device loaded active plugged LVM PV JhxC7B-YTgk-3jIU-5GVo-c4gV-W8t3-UUz06p on /dev/vda2 2
dev-disk-by\x2did-lvm\x2dpv\x2duuid\x2dJhxC7B\x2dYTgk\x2d3jIU\x2d5GVo\x2dc4gV\x2dW8t3\x2dUUz06p.device loaded active plugged LVM PV JhxC7B-YTgk-3jIU-5GVo-c4gV-W8t3-UUz06p on /dev/vda2 2
...
However, there could be an actual ID_MODEL that people are interested in
more than the fact that this is an LVM PV and so we shouldn't overwrite
the value.
Also, we already have a symlink /dev/disk/by-id/lvm-pv-uuid-<PV_UUID>
created which is then reflected as device unit (all device's symlinks
have systemd device unit representation) so we can still reach this
information in systemd unit listings even without setting the ID_MODEL.
Reported here: https://github.com/lvmteam/lvm2/issues/21
136 lines
6.2 KiB
Plaintext
136 lines
6.2 KiB
Plaintext
# Copyright (C) 2012 Red Hat, Inc. All rights reserved.
|
|
#
|
|
# This file is part of LVM2.
|
|
|
|
# Udev rules for LVM.
|
|
#
|
|
# Scan all block devices having a PV label for LVM metadata.
|
|
# Store this information in LVMetaD (the LVM metadata daemon) and maintain LVM
|
|
# metadata state for improved performance by avoiding further scans while
|
|
# running subsequent LVM commands or while using lvm2app library.
|
|
# Also, notify LVMetaD about any relevant block device removal.
|
|
#
|
|
# This rule is essential for having the information in LVMetaD up-to-date.
|
|
# It also requires blkid to be called on block devices before so only devices
|
|
# used as LVM PVs are processed (ID_FS_TYPE="LVM2_member" or "LVM1_member").
|
|
|
|
SUBSYSTEM!="block", GOTO="lvm_end"
|
|
(LVM_EXEC_RULE)
|
|
|
|
ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}=="1", GOTO="lvm_end"
|
|
|
|
# If the PV label got lost, inform lvmetad immediately.
|
|
# Detect the lost PV label by comparing previous ID_FS_TYPE value with current one.
|
|
ENV{.ID_FS_TYPE_NEW}="$env{ID_FS_TYPE}"
|
|
IMPORT{db}="ID_FS_TYPE"
|
|
ENV{ID_FS_TYPE}=="LVM2_member|LVM1_member", ENV{.ID_FS_TYPE_NEW}!="LVM2_member|LVM1_member", ENV{LVM_PV_GONE}="1"
|
|
ENV{ID_FS_TYPE}="$env{.ID_FS_TYPE_NEW}"
|
|
ENV{LVM_PV_GONE}=="1", GOTO="lvm_scan"
|
|
|
|
# Only process devices already marked as a PV - this requires blkid to be called before.
|
|
ENV{ID_FS_TYPE}!="LVM2_member|LVM1_member", GOTO="lvm_end"
|
|
ENV{DM_MULTIPATH_DEVICE_PATH}=="1", GOTO="lvm_end"
|
|
|
|
# Inform lvmetad about any PV that is gone.
|
|
ACTION=="remove", GOTO="lvm_scan"
|
|
|
|
# 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"
|
|
|
|
# If the PV is not a special device listed above, scan only if necessary.
|
|
# For "direct_pvscan" mode (see below), this means run rules only an ADD events.
|
|
# For "systemd_background" mode, systemd takes care of this by activating
|
|
# the lvm2-pvscan@.service only once.
|
|
LABEL="next"
|
|
ACTION!="(PVSCAN_ACTION)", GOTO="lvm_end"
|
|
|
|
LABEL="lvm_scan"
|
|
|
|
ENV{SYSTEMD_READY}="1"
|
|
|
|
# The method for invoking pvscan is selected at build time with the option
|
|
# --(enable|disable)-udev-systemd-background-jobs to "configure".
|
|
# On modern distributions with recent systemd, it's "systemd_background";
|
|
# on others, "direct_pvscan".
|
|
GOTO="(PVSCAN_RULE)"
|
|
|
|
LABEL="systemd_background"
|
|
|
|
# The table below summarises the situations in which we reach the LABEL="lvm_scan"
|
|
# in the "systemd_background" case.
|
|
# Marked by X, X* means only if the special dev is properly set up.
|
|
# The artificial ADD is supported for coldplugging. We avoid running the pvscan
|
|
# on artificial CHANGE so there's no unexpected autoactivation when WATCH rule fires.
|
|
# N.B. MD and loop never actually reaches lvm_scan on REMOVE as the PV label is gone
|
|
# within a CHANGE event (these are caught by the "LVM_PV_GONE" rule at the beginning).
|
|
#
|
|
# In this case, we simply set up the dependency between the device and the pvscan
|
|
# job using SYSTEMD_ALIAS (which sets up a simplified device identifier that
|
|
# allows using "BindsTo" in the sytemd unit file) and SYSTEMD_WANTS (which tells
|
|
# systemd to start the pvscan job once the device is ready).
|
|
# We need to set these variables for both "add" and "change" events, otherwise
|
|
# systemd may loose information about the device/unit dependencies.
|
|
#
|
|
# | real ADD | real CHANGE | artificial ADD | artificial CHANGE | REMOVE
|
|
# =============================================================================
|
|
# DM | | X | X* | | X
|
|
# MD | | X | X* | |
|
|
# loop | | X | X* | |
|
|
# other | X | X | X | | X
|
|
ACTION!="remove", ENV{LVM_PV_GONE}=="1", RUN+="(BINDIR)/systemd-run (LVM_EXEC)/lvm pvscan --cache $major:$minor", GOTO="lvm_end"
|
|
ENV{SYSTEMD_ALIAS}="/dev/block/$major:$minor"
|
|
ENV{SYSTEMD_WANTS}+="lvm2-pvscan@$major:$minor.service"
|
|
GOTO="lvm_end"
|
|
|
|
LABEL="direct_pvscan"
|
|
|
|
# The table below summarises the situations in which we reach the LABEL="lvm_scan"
|
|
# for the "direct_pvscan" case.
|
|
# Marked by X, X* means only if the special dev is properly set up.
|
|
# The artificial ADD is supported for coldplugging. We avoid running the pvscan
|
|
# on artificial CHANGE so there's no unexpected autoactivation when WATCH rule fires.
|
|
#
|
|
# In this case, we need to make sure that pvscan is not invoked spuriously, therefore
|
|
# we invoke it only for "add" events for "other" devices.
|
|
#
|
|
# | real ADD | real CHANGE | artificial ADD | artificial CHANGE | REMOVE
|
|
# =============================================================================
|
|
# DM | | X | X* | | X
|
|
# MD | | X | X* | |
|
|
# loop | | X | X* | |
|
|
# other | X | | X | | X
|
|
RUN+="(LVM_EXEC)/lvm pvscan --background --cache --activate ay --major $major --minor $minor", ENV{LVM_SCANNED}="1"
|
|
|
|
LABEL="lvm_end"
|