mirror of
git://sourceware.org/git/lvm2.git
synced 2024-12-21 13:34:40 +03:00
2ac217d408
Commit 756bcabbfe restricted the
situations at which the LVM autoactivation fires - only on ADD
event for devices other than DM. However, this caused a problem
for MD devices...
MD devices are activated in a very similar way as DM devices:
the MD dev is created on first appeareance of MD array member
(ADD event) and stays *inactive* until the array is complete.
Just then the MD dev turns to active state and this is reported
to userspace by CHANGE event.
Unfortunately, we can't differentiate between the CHANGE event
coming from udev trigger/WATCH rule and CHANGE event coming from
the transition to active state - MD would need to add similar logic
we already use to detect this in DM world. For now, we just have
to enable pvscan --cache on *all* CHANGE events for MD so the
autoactivation of the LVM volumes on top of MD works.
A downside of this is that a spurious CHANGE event for MD dev
can cause the LVM volumes on top of it to be automatically activated.
However, one should not open/change the device underneath until
the device above in the stack is removed! So this situation should
only happen if one opens the MD dev for read-write by mistake
(and hence firing the CHANGE event because of the WATCH udev rule),
or if calling udev trigger manually for the MD dev.
(No WHATS_NEW here as this fixes the commit mentioned
above and which has not been released yet.)
37 lines
1.4 KiB
Plaintext
37 lines
1.4 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)
|
|
|
|
# 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"
|
|
|
|
ACTION=="remove", GOTO="lvm_scan"
|
|
ACTION=="change", KERNEL=="md[0-9]*", GOTO="lvm_scan"
|
|
|
|
# If the PV is not a dm device, scan only after device addition (ADD event)
|
|
KERNEL!="dm-[0-9]*", ACTION!="add", GOTO="lvm_end"
|
|
|
|
# If the PV is a dm device, scan only after proper mapping activation (CHANGE event + DM_ACTIVATION=1)
|
|
# or after a coldplug (event retrigger) with "add" event (ADD event + DM_ACTIVATION=1)
|
|
KERNEL=="dm-[0-9]*", ENV{DM_ACTIVATION}!="1", GOTO="lvm_end"
|
|
|
|
LABEL="lvm_scan"
|
|
RUN+="(LVM_EXEC)/lvm pvscan --cache --activate ay --major $major --minor $minor"
|
|
|
|
LABEL="lvm_end"
|