shaba/lvm2
1
0
Fork 0
mirror of git://sourceware.org/git/lvm2.git synced 2024-12-22 17:35:59 +03:00
Code Releases Activity
4efed9ee99
lvm2/test/shell/autoactivation-metadata.sh

339 lines
9.2 KiB
Bash
Raw Normal View History

Add metadata-based autoactivation property for VG and LV The autoactivation property can be specified in lvcreate or vgcreate for new LVs/VGs, and the property can be changed by lvchange or vgchange for existing LVs/VGs. --setautoactivation y|n enables|disables autoactivation of a VG or LV. Autoactivation is enabled by default, which is consistent with past behavior. The disabled state is stored as a new flag in the VG metadata, and the absence of the flag allows autoactivation. If autoactivation is disabled for the VG, then no LVs in the VG will be autoactivated (the LV autoactivation property will have no effect.) When autoactivation is enabled for the VG, then autoactivation can be controlled on individual LVs. The state of this property can be reported for LVs/VGs using the "-o autoactivation" option in lvs/vgs commands, which will report "enabled", or "" for the disabled state. Previous versions of lvm do not recognize this property. Since autoactivation is enabled by default, the disabled setting will have no effect in older lvm versions. If the VG is modified by older lvm versions, the disabled state will also be dropped from the metadata. The autoactivation property is an alternative to using the lvm.conf auto_activation_volume_list, which is still applied to to VGs/LVs in addition to the new property. If VG or LV autoactivation is disabled either in metadata or in auto_activation_volume_list, it will not be autoactivated. An autoactivation command will silently skip activating an LV when the autoactivation property is disabled. To determine the effective autoactivation behavior for a specific LV, multiple settings would need to be checked: the VG autoactivation property, the LV autoactivation property, the auto_activation_volume_list. The "activation skip" property would also be relevant, since it applies to both normal and auto activation.
2021-04-02 01:20:00 +03:00
SKIP_WITH_LVMPOLLD=1
tests: skip autoactivation-metadata with lvmlockd shared vgs are not autoactivated
2021-04-09 00:08:45 +03:00
SKIP_WITH_LVMLOCKD=1
Add metadata-based autoactivation property for VG and LV The autoactivation property can be specified in lvcreate or vgcreate for new LVs/VGs, and the property can be changed by lvchange or vgchange for existing LVs/VGs. --setautoactivation y|n enables|disables autoactivation of a VG or LV. Autoactivation is enabled by default, which is consistent with past behavior. The disabled state is stored as a new flag in the VG metadata, and the absence of the flag allows autoactivation. If autoactivation is disabled for the VG, then no LVs in the VG will be autoactivated (the LV autoactivation property will have no effect.) When autoactivation is enabled for the VG, then autoactivation can be controlled on individual LVs. The state of this property can be reported for LVs/VGs using the "-o autoactivation" option in lvs/vgs commands, which will report "enabled", or "" for the disabled state. Previous versions of lvm do not recognize this property. Since autoactivation is enabled by default, the disabled setting will have no effect in older lvm versions. If the VG is modified by older lvm versions, the disabled state will also be dropped from the metadata. The autoactivation property is an alternative to using the lvm.conf auto_activation_volume_list, which is still applied to to VGs/LVs in addition to the new property. If VG or LV autoactivation is disabled either in metadata or in auto_activation_volume_list, it will not be autoactivated. An autoactivation command will silently skip activating an LV when the autoactivation property is disabled. To determine the effective autoactivation behavior for a specific LV, multiple settings would need to be checked: the VG autoactivation property, the LV autoactivation property, the auto_activation_volume_list. The "activation skip" property would also be relevant, since it applies to both normal and auto activation.
2021-04-02 01:20:00 +03:00
RUNDIR="/run"
test -d "$RUNDIR" || RUNDIR="/var/run"
PVS_ONLINE_DIR="$RUNDIR/lvm/pvs_online"
VGS_ONLINE_DIR="$RUNDIR/lvm/vgs_online"
PVS_LOOKUP_DIR="$RUNDIR/lvm/pvs_lookup"
_clear_online_files() {
# wait till udev is finished
aux udev_wait
rm -f "$PVS_ONLINE_DIR"/*
rm -f "$VGS_ONLINE_DIR"/*
rm -f "$PVS_LOOKUP_DIR"/*
}
. lib/inittest
tests: explicitely use event_activation=1 Some test do expect event_activation to be set. So add explicit configuring of this setting in tests, but also add new default which kind of does it globally as it's expected default (yet our testing rpms might be create with disabled event_activation) By adding this to each test individually - it's now easy to locate such tests...
2024-04-11 17:21:11 +03:00
aux lvmconf "global/event_activation = 1"
Add metadata-based autoactivation property for VG and LV The autoactivation property can be specified in lvcreate or vgcreate for new LVs/VGs, and the property can be changed by lvchange or vgchange for existing LVs/VGs. --setautoactivation y|n enables|disables autoactivation of a VG or LV. Autoactivation is enabled by default, which is consistent with past behavior. The disabled state is stored as a new flag in the VG metadata, and the absence of the flag allows autoactivation. If autoactivation is disabled for the VG, then no LVs in the VG will be autoactivated (the LV autoactivation property will have no effect.) When autoactivation is enabled for the VG, then autoactivation can be controlled on individual LVs. The state of this property can be reported for LVs/VGs using the "-o autoactivation" option in lvs/vgs commands, which will report "enabled", or "" for the disabled state. Previous versions of lvm do not recognize this property. Since autoactivation is enabled by default, the disabled setting will have no effect in older lvm versions. If the VG is modified by older lvm versions, the disabled state will also be dropped from the metadata. The autoactivation property is an alternative to using the lvm.conf auto_activation_volume_list, which is still applied to to VGs/LVs in addition to the new property. If VG or LV autoactivation is disabled either in metadata or in auto_activation_volume_list, it will not be autoactivated. An autoactivation command will silently skip activating an LV when the autoactivation property is disabled. To determine the effective autoactivation behavior for a specific LV, multiple settings would need to be checked: the VG autoactivation property, the LV autoactivation property, the auto_activation_volume_list. The "activation skip" property would also be relevant, since it applies to both normal and auto activation.
2021-04-02 01:20:00 +03:00
aux prepare_devs 1
#
# test lvchange --setautoactivation
#
# default
tests: skip autoactivation-metadata with lvmlockd shared vgs are not autoactivated
2021-04-09 00:08:45 +03:00
vgcreate $vg "$dev1"
Add metadata-based autoactivation property for VG and LV The autoactivation property can be specified in lvcreate or vgcreate for new LVs/VGs, and the property can be changed by lvchange or vgchange for existing LVs/VGs. --setautoactivation y|n enables|disables autoactivation of a VG or LV. Autoactivation is enabled by default, which is consistent with past behavior. The disabled state is stored as a new flag in the VG metadata, and the absence of the flag allows autoactivation. If autoactivation is disabled for the VG, then no LVs in the VG will be autoactivated (the LV autoactivation property will have no effect.) When autoactivation is enabled for the VG, then autoactivation can be controlled on individual LVs. The state of this property can be reported for LVs/VGs using the "-o autoactivation" option in lvs/vgs commands, which will report "enabled", or "" for the disabled state. Previous versions of lvm do not recognize this property. Since autoactivation is enabled by default, the disabled setting will have no effect in older lvm versions. If the VG is modified by older lvm versions, the disabled state will also be dropped from the metadata. The autoactivation property is an alternative to using the lvm.conf auto_activation_volume_list, which is still applied to to VGs/LVs in addition to the new property. If VG or LV autoactivation is disabled either in metadata or in auto_activation_volume_list, it will not be autoactivated. An autoactivation command will silently skip activating an LV when the autoactivation property is disabled. To determine the effective autoactivation behavior for a specific LV, multiple settings would need to be checked: the VG autoactivation property, the LV autoactivation property, the auto_activation_volume_list. The "activation skip" property would also be relevant, since it applies to both normal and auto activation.
2021-04-02 01:20:00 +03:00
lvcreate -n $lv1 -l1 -an $vg
check vg_field $vg autoactivation "enabled"
check lv_field $vg/$lv1 autoactivation "enabled"
lvchange -aay $vg/$lv1
check lv_field $vg/$lv1 lv_active "active"
lvchange -an $vg/$lv1
lvchange -aay $vg
check lv_field $vg/$lv1 lv_active "active"
lvchange -an $vg/$lv1
vgchange -aay $vg
check lv_field $vg/$lv1 lv_active "active"
lvchange -an $vg/$lv1
pvscan --cache -aay "$dev1"
check lv_field $vg/$lv1 lv_active "active"
lvchange -an $vg/$lv1
_clear_online_files
# --aa=n
lvchange --setautoactivation n $vg/$lv1
check vg_field $vg autoactivation "enabled"
check lv_field $vg/$lv1 autoactivation ""
lvchange -aay $vg/$lv1
check lv_field $vg/$lv1 lv_active ""
lvchange -aay $vg
check lv_field $vg/$lv1 lv_active ""
vgchange -aay $vg
check lv_field $vg/$lv1 lv_active ""
pvscan --cache -aay "$dev1"
check lv_field $vg/$lv1 lv_active ""
_clear_online_files
# --aa=y
lvchange --setautoactivation y $vg/$lv1
check vg_field $vg autoactivation "enabled"
check lv_field $vg/$lv1 autoactivation "enabled"
lvchange -aay $vg/$lv1
check lv_field $vg/$lv1 lv_active "active"
lvchange -an $vg/$lv1
lvchange -aay $vg
check lv_field $vg/$lv1 lv_active "active"
lvchange -an $vg/$lv1
vgchange -aay $vg
check lv_field $vg/$lv1 lv_active "active"
lvchange -an $vg/$lv1
pvscan --cache -aay "$dev1"
check lv_field $vg/$lv1 lv_active "active"
lvchange -an $vg/$lv1
_clear_online_files
vgremove -y $vg
#
# test vgchange --setautoactivation
#
# default
tests: skip autoactivation-metadata with lvmlockd shared vgs are not autoactivated
2021-04-09 00:08:45 +03:00
vgcreate $vg "$dev1"
Add metadata-based autoactivation property for VG and LV The autoactivation property can be specified in lvcreate or vgcreate for new LVs/VGs, and the property can be changed by lvchange or vgchange for existing LVs/VGs. --setautoactivation y|n enables|disables autoactivation of a VG or LV. Autoactivation is enabled by default, which is consistent with past behavior. The disabled state is stored as a new flag in the VG metadata, and the absence of the flag allows autoactivation. If autoactivation is disabled for the VG, then no LVs in the VG will be autoactivated (the LV autoactivation property will have no effect.) When autoactivation is enabled for the VG, then autoactivation can be controlled on individual LVs. The state of this property can be reported for LVs/VGs using the "-o autoactivation" option in lvs/vgs commands, which will report "enabled", or "" for the disabled state. Previous versions of lvm do not recognize this property. Since autoactivation is enabled by default, the disabled setting will have no effect in older lvm versions. If the VG is modified by older lvm versions, the disabled state will also be dropped from the metadata. The autoactivation property is an alternative to using the lvm.conf auto_activation_volume_list, which is still applied to to VGs/LVs in addition to the new property. If VG or LV autoactivation is disabled either in metadata or in auto_activation_volume_list, it will not be autoactivated. An autoactivation command will silently skip activating an LV when the autoactivation property is disabled. To determine the effective autoactivation behavior for a specific LV, multiple settings would need to be checked: the VG autoactivation property, the LV autoactivation property, the auto_activation_volume_list. The "activation skip" property would also be relevant, since it applies to both normal and auto activation.
2021-04-02 01:20:00 +03:00
lvcreate -n $lv1 -l1 -an $vg
# --aa=n
vgchange --setautoactivation n $vg
check vg_field $vg autoactivation ""
check lv_field $vg/$lv1 autoactivation "enabled"
lvchange -aay $vg/$lv1
check lv_field $vg/$lv1 lv_active ""
lvchange -aay $vg
check lv_field $vg/$lv1 lv_active ""
vgchange -aay $vg
check lv_field $vg/$lv1 lv_active ""
pvscan --cache -aay "$dev1"
check lv_field $vg/$lv1 lv_active ""
_clear_online_files
# --aa=y
vgchange --setautoactivation y $vg
check vg_field $vg autoactivation "enabled"
check lv_field $vg/$lv1 autoactivation "enabled"
lvchange -aay $vg/$lv1
check lv_field $vg/$lv1 lv_active "active"
lvchange -an $vg/$lv1
lvchange -aay $vg
check lv_field $vg/$lv1 lv_active "active"
lvchange -an $vg/$lv1
vgchange -aay $vg
check lv_field $vg/$lv1 lv_active "active"
lvchange -an $vg/$lv1
pvscan --cache -aay "$dev1"
check lv_field $vg/$lv1 lv_active "active"
lvchange -an $vg/$lv1
_clear_online_files
vgremove -y $vg
#
# test vgcreate --setautoactivation, lvcreate --setautoactivation
#
tests: skip autoactivation-metadata with lvmlockd shared vgs are not autoactivated
2021-04-09 00:08:45 +03:00
vgcreate $vg "$dev1"
Add metadata-based autoactivation property for VG and LV The autoactivation property can be specified in lvcreate or vgcreate for new LVs/VGs, and the property can be changed by lvchange or vgchange for existing LVs/VGs. --setautoactivation y|n enables|disables autoactivation of a VG or LV. Autoactivation is enabled by default, which is consistent with past behavior. The disabled state is stored as a new flag in the VG metadata, and the absence of the flag allows autoactivation. If autoactivation is disabled for the VG, then no LVs in the VG will be autoactivated (the LV autoactivation property will have no effect.) When autoactivation is enabled for the VG, then autoactivation can be controlled on individual LVs. The state of this property can be reported for LVs/VGs using the "-o autoactivation" option in lvs/vgs commands, which will report "enabled", or "" for the disabled state. Previous versions of lvm do not recognize this property. Since autoactivation is enabled by default, the disabled setting will have no effect in older lvm versions. If the VG is modified by older lvm versions, the disabled state will also be dropped from the metadata. The autoactivation property is an alternative to using the lvm.conf auto_activation_volume_list, which is still applied to to VGs/LVs in addition to the new property. If VG or LV autoactivation is disabled either in metadata or in auto_activation_volume_list, it will not be autoactivated. An autoactivation command will silently skip activating an LV when the autoactivation property is disabled. To determine the effective autoactivation behavior for a specific LV, multiple settings would need to be checked: the VG autoactivation property, the LV autoactivation property, the auto_activation_volume_list. The "activation skip" property would also be relevant, since it applies to both normal and auto activation.
2021-04-02 01:20:00 +03:00
lvcreate -n $lv1 -l1 -an $vg
lvcreate -n $lv2 -l1 --setautoactivation y -an $vg
lvcreate -n $lv3 -l1 --setautoactivation n -an $vg
check vg_field $vg autoactivation "enabled"
check lv_field $vg/$lv1 autoactivation "enabled"
check lv_field $vg/$lv2 autoactivation "enabled"
check lv_field $vg/$lv3 autoactivation ""
vgchange -aay $vg
check lv_field $vg/$lv1 lv_active "active"
check lv_field $vg/$lv2 lv_active "active"
check lv_field $vg/$lv3 lv_active ""
vgchange -an $vg
lvchange -aay $vg/$lv1
lvchange -aay $vg/$lv2
lvchange -aay $vg/$lv3
check lv_field $vg/$lv1 lv_active "active"
check lv_field $vg/$lv2 lv_active "active"
check lv_field $vg/$lv3 lv_active ""
vgchange -an $vg
pvscan --cache -aay "$dev1"
check lv_field $vg/$lv1 lv_active "active"
check lv_field $vg/$lv2 lv_active "active"
check lv_field $vg/$lv3 lv_active ""
vgchange -an $vg
vgremove -y $vg
_clear_online_files
tests: skip autoactivation-metadata with lvmlockd shared vgs are not autoactivated
2021-04-09 00:08:45 +03:00
vgcreate --setautoactivation y $vg "$dev1"
Add metadata-based autoactivation property for VG and LV The autoactivation property can be specified in lvcreate or vgcreate for new LVs/VGs, and the property can be changed by lvchange or vgchange for existing LVs/VGs. --setautoactivation y|n enables|disables autoactivation of a VG or LV. Autoactivation is enabled by default, which is consistent with past behavior. The disabled state is stored as a new flag in the VG metadata, and the absence of the flag allows autoactivation. If autoactivation is disabled for the VG, then no LVs in the VG will be autoactivated (the LV autoactivation property will have no effect.) When autoactivation is enabled for the VG, then autoactivation can be controlled on individual LVs. The state of this property can be reported for LVs/VGs using the "-o autoactivation" option in lvs/vgs commands, which will report "enabled", or "" for the disabled state. Previous versions of lvm do not recognize this property. Since autoactivation is enabled by default, the disabled setting will have no effect in older lvm versions. If the VG is modified by older lvm versions, the disabled state will also be dropped from the metadata. The autoactivation property is an alternative to using the lvm.conf auto_activation_volume_list, which is still applied to to VGs/LVs in addition to the new property. If VG or LV autoactivation is disabled either in metadata or in auto_activation_volume_list, it will not be autoactivated. An autoactivation command will silently skip activating an LV when the autoactivation property is disabled. To determine the effective autoactivation behavior for a specific LV, multiple settings would need to be checked: the VG autoactivation property, the LV autoactivation property, the auto_activation_volume_list. The "activation skip" property would also be relevant, since it applies to both normal and auto activation.
2021-04-02 01:20:00 +03:00
lvcreate -n $lv1 -l1 -an $vg
lvcreate -n $lv2 -l1 --setautoactivation y -an $vg
lvcreate -n $lv3 -l1 --setautoactivation n -an $vg
check vg_field $vg autoactivation "enabled"
check lv_field $vg/$lv1 autoactivation "enabled"
check lv_field $vg/$lv2 autoactivation "enabled"
check lv_field $vg/$lv3 autoactivation ""
vgchange -aay $vg
check lv_field $vg/$lv1 lv_active "active"
check lv_field $vg/$lv2 lv_active "active"
check lv_field $vg/$lv3 lv_active ""
vgchange -an $vg
lvchange -aay $vg/$lv1
lvchange -aay $vg/$lv2
lvchange -aay $vg/$lv3
check lv_field $vg/$lv1 lv_active "active"
check lv_field $vg/$lv2 lv_active "active"
check lv_field $vg/$lv3 lv_active ""
vgchange -an $vg
pvscan --cache -aay "$dev1"
check lv_field $vg/$lv1 lv_active "active"
check lv_field $vg/$lv2 lv_active "active"
check lv_field $vg/$lv3 lv_active ""
vgchange -an $vg
vgremove -y $vg
_clear_online_files
tests: skip autoactivation-metadata with lvmlockd shared vgs are not autoactivated
2021-04-09 00:08:45 +03:00
vgcreate --setautoactivation n $vg "$dev1"
Add metadata-based autoactivation property for VG and LV The autoactivation property can be specified in lvcreate or vgcreate for new LVs/VGs, and the property can be changed by lvchange or vgchange for existing LVs/VGs. --setautoactivation y|n enables|disables autoactivation of a VG or LV. Autoactivation is enabled by default, which is consistent with past behavior. The disabled state is stored as a new flag in the VG metadata, and the absence of the flag allows autoactivation. If autoactivation is disabled for the VG, then no LVs in the VG will be autoactivated (the LV autoactivation property will have no effect.) When autoactivation is enabled for the VG, then autoactivation can be controlled on individual LVs. The state of this property can be reported for LVs/VGs using the "-o autoactivation" option in lvs/vgs commands, which will report "enabled", or "" for the disabled state. Previous versions of lvm do not recognize this property. Since autoactivation is enabled by default, the disabled setting will have no effect in older lvm versions. If the VG is modified by older lvm versions, the disabled state will also be dropped from the metadata. The autoactivation property is an alternative to using the lvm.conf auto_activation_volume_list, which is still applied to to VGs/LVs in addition to the new property. If VG or LV autoactivation is disabled either in metadata or in auto_activation_volume_list, it will not be autoactivated. An autoactivation command will silently skip activating an LV when the autoactivation property is disabled. To determine the effective autoactivation behavior for a specific LV, multiple settings would need to be checked: the VG autoactivation property, the LV autoactivation property, the auto_activation_volume_list. The "activation skip" property would also be relevant, since it applies to both normal and auto activation.
2021-04-02 01:20:00 +03:00
lvcreate -n $lv1 -l1 -an $vg
lvcreate -n $lv2 -l1 --setautoactivation y -an $vg
lvcreate -n $lv3 -l1 --setautoactivation n -an $vg
check vg_field $vg autoactivation ""
check lv_field $vg/$lv1 autoactivation "enabled"
check lv_field $vg/$lv2 autoactivation "enabled"
check lv_field $vg/$lv3 autoactivation ""
vgchange -aay $vg
check lv_field $vg/$lv1 lv_active ""
check lv_field $vg/$lv2 lv_active ""
check lv_field $vg/$lv3 lv_active ""
lvchange -aay $vg/$lv1
lvchange -aay $vg/$lv2
lvchange -aay $vg/$lv3
check lv_field $vg/$lv1 lv_active ""
check lv_field $vg/$lv2 lv_active ""
check lv_field $vg/$lv3 lv_active ""
pvscan --cache -aay "$dev1"
check lv_field $vg/$lv1 lv_active ""
check lv_field $vg/$lv2 lv_active ""
check lv_field $vg/$lv3 lv_active ""
vgremove -y $vg
_clear_online_files
#
# test combination of --aa and auto_activation_volume_list
#
tests: skip autoactivation-metadata with lvmlockd shared vgs are not autoactivated
2021-04-09 00:08:45 +03:00
vgcreate $vg "$dev1"
Add metadata-based autoactivation property for VG and LV The autoactivation property can be specified in lvcreate or vgcreate for new LVs/VGs, and the property can be changed by lvchange or vgchange for existing LVs/VGs. --setautoactivation y|n enables|disables autoactivation of a VG or LV. Autoactivation is enabled by default, which is consistent with past behavior. The disabled state is stored as a new flag in the VG metadata, and the absence of the flag allows autoactivation. If autoactivation is disabled for the VG, then no LVs in the VG will be autoactivated (the LV autoactivation property will have no effect.) When autoactivation is enabled for the VG, then autoactivation can be controlled on individual LVs. The state of this property can be reported for LVs/VGs using the "-o autoactivation" option in lvs/vgs commands, which will report "enabled", or "" for the disabled state. Previous versions of lvm do not recognize this property. Since autoactivation is enabled by default, the disabled setting will have no effect in older lvm versions. If the VG is modified by older lvm versions, the disabled state will also be dropped from the metadata. The autoactivation property is an alternative to using the lvm.conf auto_activation_volume_list, which is still applied to to VGs/LVs in addition to the new property. If VG or LV autoactivation is disabled either in metadata or in auto_activation_volume_list, it will not be autoactivated. An autoactivation command will silently skip activating an LV when the autoactivation property is disabled. To determine the effective autoactivation behavior for a specific LV, multiple settings would need to be checked: the VG autoactivation property, the LV autoactivation property, the auto_activation_volume_list. The "activation skip" property would also be relevant, since it applies to both normal and auto activation.
2021-04-02 01:20:00 +03:00
lvcreate -n $lv1 -l1 -an $vg
lvcreate -n $lv2 -l1 --setautoactivation n -an $vg
check vg_field $vg autoactivation "enabled"
check lv_field $vg/$lv1 autoactivation "enabled"
check lv_field $vg/$lv2 autoactivation ""
# list prevents all aa, metadata settings don't matter
aux lvmconf "activation/auto_activation_volume_list = [ ]"
vgchange -aay $vg
check lv_field $vg/$lv1 lv_active ""
check lv_field $vg/$lv2 lv_active ""
vgchange -an $vg
lvchange -aay $vg/$lv1
lvchange -aay $vg/$lv2
check lv_field $vg/$lv1 lv_active ""
check lv_field $vg/$lv2 lv_active ""
vgchange -an $vg
pvscan --cache -aay "$dev1"
check lv_field $vg/$lv1 lv_active ""
check lv_field $vg/$lv2 lv_active ""
vgchange -an $vg
_clear_online_files
# list allows all vg aa, metadata allows lv1 -> lv1 activated
aux lvmconf "activation/auto_activation_volume_list = [ \"$vg\" ]"
vgchange -aay $vg
check lv_field $vg/$lv1 lv_active "active"
check lv_field $vg/$lv2 lv_active ""
vgchange -an $vg
lvchange -aay $vg/$lv1
lvchange -aay $vg/$lv2
check lv_field $vg/$lv1 lv_active "active"
check lv_field $vg/$lv2 lv_active ""
vgchange -an $vg
pvscan --cache -aay "$dev1"
check lv_field $vg/$lv1 lv_active "active"
check lv_field $vg/$lv2 lv_active ""
vgchange -an $vg
_clear_online_files
# list allows lv1, metadata allows lv1 -> lv1 activated
aux lvmconf "activation/auto_activation_volume_list = [ \"$vg/$lv1\" ]"
vgchange -aay $vg
check lv_field $vg/$lv1 lv_active "active"
check lv_field $vg/$lv2 lv_active ""
vgchange -an $vg
lvchange -aay $vg/$lv1
lvchange -aay $vg/$lv2
check lv_field $vg/$lv1 lv_active "active"
check lv_field $vg/$lv2 lv_active ""
vgchange -an $vg
pvscan --cache -aay "$dev1"
check lv_field $vg/$lv1 lv_active "active"
check lv_field $vg/$lv2 lv_active ""
vgchange -an $vg
_clear_online_files
# list allows lv2, metadata allows lv1 -> nothing activated
aux lvmconf "activation/auto_activation_volume_list = [ \"$vg/$lv2\" ]"
vgchange -aay $vg
check lv_field $vg/$lv1 lv_active ""
check lv_field $vg/$lv2 lv_active ""
vgchange -an $vg
lvchange -aay $vg/$lv1
lvchange -aay $vg/$lv2
check lv_field $vg/$lv1 lv_active ""
check lv_field $vg/$lv2 lv_active ""
vgchange -an $vg
pvscan --cache -aay "$dev1"
check lv_field $vg/$lv1 lv_active ""
check lv_field $vg/$lv2 lv_active ""
vgchange -an $vg
_clear_online_files
vgremove -y $vg
tests: skip autoactivation-metadata with lvmlockd shared vgs are not autoactivated
2021-04-09 00:08:45 +03:00
vgcreate --setautoactivation n $vg "$dev1"
Add metadata-based autoactivation property for VG and LV The autoactivation property can be specified in lvcreate or vgcreate for new LVs/VGs, and the property can be changed by lvchange or vgchange for existing LVs/VGs. --setautoactivation y|n enables|disables autoactivation of a VG or LV. Autoactivation is enabled by default, which is consistent with past behavior. The disabled state is stored as a new flag in the VG metadata, and the absence of the flag allows autoactivation. If autoactivation is disabled for the VG, then no LVs in the VG will be autoactivated (the LV autoactivation property will have no effect.) When autoactivation is enabled for the VG, then autoactivation can be controlled on individual LVs. The state of this property can be reported for LVs/VGs using the "-o autoactivation" option in lvs/vgs commands, which will report "enabled", or "" for the disabled state. Previous versions of lvm do not recognize this property. Since autoactivation is enabled by default, the disabled setting will have no effect in older lvm versions. If the VG is modified by older lvm versions, the disabled state will also be dropped from the metadata. The autoactivation property is an alternative to using the lvm.conf auto_activation_volume_list, which is still applied to to VGs/LVs in addition to the new property. If VG or LV autoactivation is disabled either in metadata or in auto_activation_volume_list, it will not be autoactivated. An autoactivation command will silently skip activating an LV when the autoactivation property is disabled. To determine the effective autoactivation behavior for a specific LV, multiple settings would need to be checked: the VG autoactivation property, the LV autoactivation property, the auto_activation_volume_list. The "activation skip" property would also be relevant, since it applies to both normal and auto activation.
2021-04-02 01:20:00 +03:00
lvcreate -n $lv1 -l1 -an $vg
lvcreate -n $lv2 -l1 --setautoactivation n -an $vg
check vg_field $vg autoactivation ""
check lv_field $vg/$lv1 autoactivation "enabled"
check lv_field $vg/$lv2 autoactivation ""
# list prevents all aa, metadata settings don't matter
aux lvmconf "activation/auto_activation_volume_list = [ ]"
vgchange -aay $vg
check lv_field $vg/$lv1 lv_active ""
check lv_field $vg/$lv2 lv_active ""
vgchange -an $vg
lvchange -aay $vg/$lv1
lvchange -aay $vg/$lv2
check lv_field $vg/$lv1 lv_active ""
check lv_field $vg/$lv2 lv_active ""
vgchange -an $vg
pvscan --cache -aay "$dev1"
check lv_field $vg/$lv1 lv_active ""
check lv_field $vg/$lv2 lv_active ""
vgchange -an $vg
_clear_online_files
# list allows lv1, metadata disallows vg -> nothing activated
aux lvmconf "activation/auto_activation_volume_list = [ \"$vg/$lv1\" ]"
vgchange -aay $vg
check lv_field $vg/$lv1 lv_active ""
check lv_field $vg/$lv2 lv_active ""
vgchange -an $vg
lvchange -aay $vg/$lv1
lvchange -aay $vg/$lv2
check lv_field $vg/$lv1 lv_active ""
check lv_field $vg/$lv2 lv_active ""
vgchange -an $vg
pvscan --cache -aay "$dev1"
check lv_field $vg/$lv1 lv_active ""
check lv_field $vg/$lv2 lv_active ""
vgchange -an $vg
_clear_online_files
vgremove -y $vg
Copy Permalink