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
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
aux prepare_devs 1
#
# test lvchange --setautoactivation
#
# default
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
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
#
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
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
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
#
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
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
