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
7d11d708d8
lvm2/test/t-vgextend-usage.sh

130 lines
3.5 KiB
Bash
Raw Normal View History

Add --pvmetadatacopies as a synonym for --metadatacopies in various commands. Going forward, we would like to allow users to specify the total number of metadatacopies in a VG rather than on a per-PV basis. In order to facilitate that, introduce --pvmetadatacopes to replace --metadatacopies everywhere. We still allow --metadatacopies for pv commands, but require --pvmetadatacopies for vg commands. Eventually we will introduce --vgmetadatacopies. Once we do that, we should either deprecate --metadatacopies or make it a synonym based on the command (pvmetadatacopies for pv commands, and vgmetadatacopies for vg commands). The latter option would likely just require a simple 'strncpy' check against cmd->command->name to qualify the merge_synonym call. Update nightly tests to cover the pvmetadatacopies synonym. Note that this patch is the result of an eariler review comment for the implicit pvcreate patches. Should apply cleanly on top of the implicit pvcreate patches (I applied after patch 10/10 in that series). NOTE: This patch will require --pvmetadatacopies for vgconvert as --metadatacopies is no longer accepted.
2009-10-06 00:53:41 +04:00
# Copyright (C) 2008 Red Hat, Inc. All rights reserved.
#
# This copyrighted material is made available to anyone wishing to use,
# modify, copy, or redistribute it subject to the terms and conditions
# of the GNU General Public License v.2.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software Foundation,
# Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
#
# Exercise various vgextend commands
#
. ./test-utils.sh
aux prepare_devs 5
for mdatype in 1 2
do
# Explicit pvcreate
pvcreate -M$mdatype $dev1 $dev2 $dev3 $dev4 $dev5
vgcreate -M$mdatype $vg1 $dev1 $dev2
vgextend $vg1 $dev3 $dev4 $dev5
vgremove -ff $vg1
# Implicit pvcreate
pvremove $dev1 $dev2 $dev3 $dev4 $dev5
vgcreate -M$mdatype $vg1 $dev1 $dev2
vgextend -M$mdatype $vg1 $dev3 $dev4 $dev5
vgremove -ff $vg1
pvremove $dev1 $dev2 $dev3 $dev4 $dev5
done
# Implicit pvcreate tests, test pvcreate options on vgcreate
# --force, --yes, --metadata{size|copies|type}, --zero
# --dataalignment[offset]
vgcreate $vg $dev2
vgextend --force --yes --zero y $vg $dev1
vgreduce $vg $dev1
pvremove -f $dev1
for i in 0 1 2 3
do
# vgcreate (lvm2) succeeds writing LVM label at sector $i
vgextend --labelsector $i $vg $dev1
dd if=$dev1 bs=512 skip=$i count=1 2>/dev/null | strings | grep -q LABELONE;
vgreduce $vg $dev1
pvremove -f $dev1
done
Add --pvmetadatacopies as a synonym for --metadatacopies in various commands. Going forward, we would like to allow users to specify the total number of metadatacopies in a VG rather than on a per-PV basis. In order to facilitate that, introduce --pvmetadatacopes to replace --metadatacopies everywhere. We still allow --metadatacopies for pv commands, but require --pvmetadatacopies for vg commands. Eventually we will introduce --vgmetadatacopies. Once we do that, we should either deprecate --metadatacopies or make it a synonym based on the command (pvmetadatacopies for pv commands, and vgmetadatacopies for vg commands). The latter option would likely just require a simple 'strncpy' check against cmd->command->name to qualify the merge_synonym call. Update nightly tests to cover the pvmetadatacopies synonym. Note that this patch is the result of an eariler review comment for the implicit pvcreate patches. Should apply cleanly on top of the implicit pvcreate patches (I applied after patch 10/10 in that series). NOTE: This patch will require --pvmetadatacopies for vgconvert as --metadatacopies is no longer accepted.
2009-10-06 00:55:56 +04:00
# pvmetadatacopies
Add --pvmetadatacopies as a synonym for --metadatacopies in various commands. Going forward, we would like to allow users to specify the total number of metadatacopies in a VG rather than on a per-PV basis. In order to facilitate that, introduce --pvmetadatacopes to replace --metadatacopies everywhere. We still allow --metadatacopies for pv commands, but require --pvmetadatacopies for vg commands. Eventually we will introduce --vgmetadatacopies. Once we do that, we should either deprecate --metadatacopies or make it a synonym based on the command (pvmetadatacopies for pv commands, and vgmetadatacopies for vg commands). The latter option would likely just require a simple 'strncpy' check against cmd->command->name to qualify the merge_synonym call. Update nightly tests to cover the pvmetadatacopies synonym. Note that this patch is the result of an eariler review comment for the implicit pvcreate patches. Should apply cleanly on top of the implicit pvcreate patches (I applied after patch 10/10 in that series). NOTE: This patch will require --pvmetadatacopies for vgconvert as --metadatacopies is no longer accepted.
2009-10-06 00:53:41 +04:00
for i in 0 1 2
do
Add --pvmetadatacopies as a synonym for --metadatacopies in various commands. Going forward, we would like to allow users to specify the total number of metadatacopies in a VG rather than on a per-PV basis. In order to facilitate that, introduce --pvmetadatacopes to replace --metadatacopies everywhere. We still allow --metadatacopies for pv commands, but require --pvmetadatacopies for vg commands. Eventually we will introduce --vgmetadatacopies. Once we do that, we should either deprecate --metadatacopies or make it a synonym based on the command (pvmetadatacopies for pv commands, and vgmetadatacopies for vg commands). The latter option would likely just require a simple 'strncpy' check against cmd->command->name to qualify the merge_synonym call. Update nightly tests to cover the pvmetadatacopies synonym. Note that this patch is the result of an eariler review comment for the implicit pvcreate patches. Should apply cleanly on top of the implicit pvcreate patches (I applied after patch 10/10 in that series). NOTE: This patch will require --pvmetadatacopies for vgconvert as --metadatacopies is no longer accepted.
2009-10-06 00:55:56 +04:00
vgextend --pvmetadatacopies $i $vg $dev1
Add --pvmetadatacopies as a synonym for --metadatacopies in various commands. Going forward, we would like to allow users to specify the total number of metadatacopies in a VG rather than on a per-PV basis. In order to facilitate that, introduce --pvmetadatacopes to replace --metadatacopies everywhere. We still allow --metadatacopies for pv commands, but require --pvmetadatacopies for vg commands. Eventually we will introduce --vgmetadatacopies. Once we do that, we should either deprecate --metadatacopies or make it a synonym based on the command (pvmetadatacopies for pv commands, and vgmetadatacopies for vg commands). The latter option would likely just require a simple 'strncpy' check against cmd->command->name to qualify the merge_synonym call. Update nightly tests to cover the pvmetadatacopies synonym. Note that this patch is the result of an eariler review comment for the implicit pvcreate patches. Should apply cleanly on top of the implicit pvcreate patches (I applied after patch 10/10 in that series). NOTE: This patch will require --pvmetadatacopies for vgconvert as --metadatacopies is no longer accepted.
2009-10-06 00:53:41 +04:00
check_pv_field_ $dev1 pv_mda_count $i
vgreduce $vg $dev1
pvremove -f $dev1
done
# metadatasize, dataalignment, dataalignmentoffset
#COMM 'pvcreate sets data offset next to mda area'
vgextend --metadatasize 100k --dataalignment 100k $vg $dev1
check_pv_field_ $dev1 pe_start 200.00k
vgreduce $vg $dev1
pvremove -f $dev1
Change default alignment of pe_start to 1MB. The new standard in the storage industry is to default alignment of data areas to 1MB. fdisk, parted, and mdadm have all been updated to this default. Update LVM to align the PV's data area start (pe_start) to 1MB. This provides a more useful default than the previous default of 64K (which generally ended up being a 192K pe_start once the first metadata area was created). Before this patch: # pvs -o name,vg_mda_size,pe_start PV VMdaSize 1st PE /dev/sdd 188.00k 192.00k After this patch: # pvs -o name,vg_mda_size,pe_start PV VMdaSize 1st PE /dev/sdd 1020.00k 1.00m The heuristic for setting the default alignment for LVM data areas is: - If the default value (1MB) is a multiple of the detected alignment then just use the default. - Otherwise, use the detected value. In practice this means we'll almost always use 1MB -- that is unless: - the alignment was explicitly specified with --dataalignment - or MD's full stripe width, or the {minimum,optimal}_io_size exceeds 1MB - or the specified/detected value is not a power-of-2
2010-08-12 08:11:48 +04:00
# data area is aligned to 1M by default,
Add --pvmetadatacopies as a synonym for --metadatacopies in various commands. Going forward, we would like to allow users to specify the total number of metadatacopies in a VG rather than on a per-PV basis. In order to facilitate that, introduce --pvmetadatacopes to replace --metadatacopies everywhere. We still allow --metadatacopies for pv commands, but require --pvmetadatacopies for vg commands. Eventually we will introduce --vgmetadatacopies. Once we do that, we should either deprecate --metadatacopies or make it a synonym based on the command (pvmetadatacopies for pv commands, and vgmetadatacopies for vg commands). The latter option would likely just require a simple 'strncpy' check against cmd->command->name to qualify the merge_synonym call. Update nightly tests to cover the pvmetadatacopies synonym. Note that this patch is the result of an eariler review comment for the implicit pvcreate patches. Should apply cleanly on top of the implicit pvcreate patches (I applied after patch 10/10 in that series). NOTE: This patch will require --pvmetadatacopies for vgconvert as --metadatacopies is no longer accepted.
2009-10-06 00:53:41 +04:00
# data area start is shifted by the specified alignment_offset
Change default alignment of pe_start to 1MB. The new standard in the storage industry is to default alignment of data areas to 1MB. fdisk, parted, and mdadm have all been updated to this default. Update LVM to align the PV's data area start (pe_start) to 1MB. This provides a more useful default than the previous default of 64K (which generally ended up being a 192K pe_start once the first metadata area was created). Before this patch: # pvs -o name,vg_mda_size,pe_start PV VMdaSize 1st PE /dev/sdd 188.00k 192.00k After this patch: # pvs -o name,vg_mda_size,pe_start PV VMdaSize 1st PE /dev/sdd 1020.00k 1.00m The heuristic for setting the default alignment for LVM data areas is: - If the default value (1MB) is a multiple of the detected alignment then just use the default. - Otherwise, use the detected value. In practice this means we'll almost always use 1MB -- that is unless: - the alignment was explicitly specified with --dataalignment - or MD's full stripe width, or the {minimum,optimal}_io_size exceeds 1MB - or the specified/detected value is not a power-of-2
2010-08-12 08:11:48 +04:00
pv_align="1052160B" # 1048576 + (7*512)
Add --pvmetadatacopies as a synonym for --metadatacopies in various commands. Going forward, we would like to allow users to specify the total number of metadatacopies in a VG rather than on a per-PV basis. In order to facilitate that, introduce --pvmetadatacopes to replace --metadatacopies everywhere. We still allow --metadatacopies for pv commands, but require --pvmetadatacopies for vg commands. Eventually we will introduce --vgmetadatacopies. Once we do that, we should either deprecate --metadatacopies or make it a synonym based on the command (pvmetadatacopies for pv commands, and vgmetadatacopies for vg commands). The latter option would likely just require a simple 'strncpy' check against cmd->command->name to qualify the merge_synonym call. Update nightly tests to cover the pvmetadatacopies synonym. Note that this patch is the result of an eariler review comment for the implicit pvcreate patches. Should apply cleanly on top of the implicit pvcreate patches (I applied after patch 10/10 in that series). NOTE: This patch will require --pvmetadatacopies for vgconvert as --metadatacopies is no longer accepted.
2009-10-06 00:53:41 +04:00
vgextend --metadatasize 128k --dataalignmentoffset 7s $vg $dev1
Change default alignment of pe_start to 1MB. The new standard in the storage industry is to default alignment of data areas to 1MB. fdisk, parted, and mdadm have all been updated to this default. Update LVM to align the PV's data area start (pe_start) to 1MB. This provides a more useful default than the previous default of 64K (which generally ended up being a 192K pe_start once the first metadata area was created). Before this patch: # pvs -o name,vg_mda_size,pe_start PV VMdaSize 1st PE /dev/sdd 188.00k 192.00k After this patch: # pvs -o name,vg_mda_size,pe_start PV VMdaSize 1st PE /dev/sdd 1020.00k 1.00m The heuristic for setting the default alignment for LVM data areas is: - If the default value (1MB) is a multiple of the detected alignment then just use the default. - Otherwise, use the detected value. In practice this means we'll almost always use 1MB -- that is unless: - the alignment was explicitly specified with --dataalignment - or MD's full stripe width, or the {minimum,optimal}_io_size exceeds 1MB - or the specified/detected value is not a power-of-2
2010-08-12 08:11:48 +04:00
check_pv_field_ $dev1 pe_start $pv_align "--units b"
Add --pvmetadatacopies as a synonym for --metadatacopies in various commands. Going forward, we would like to allow users to specify the total number of metadatacopies in a VG rather than on a per-PV basis. In order to facilitate that, introduce --pvmetadatacopes to replace --metadatacopies everywhere. We still allow --metadatacopies for pv commands, but require --pvmetadatacopies for vg commands. Eventually we will introduce --vgmetadatacopies. Once we do that, we should either deprecate --metadatacopies or make it a synonym based on the command (pvmetadatacopies for pv commands, and vgmetadatacopies for vg commands). The latter option would likely just require a simple 'strncpy' check against cmd->command->name to qualify the merge_synonym call. Update nightly tests to cover the pvmetadatacopies synonym. Note that this patch is the result of an eariler review comment for the implicit pvcreate patches. Should apply cleanly on top of the implicit pvcreate patches (I applied after patch 10/10 in that series). NOTE: This patch will require --pvmetadatacopies for vgconvert as --metadatacopies is no longer accepted.
2009-10-06 00:53:41 +04:00
vgremove -f $vg
pvremove -f $dev1
Add to vgcreate and vgextend nightly tests.
2009-10-31 19:43:07 +03:00
# vgextend fails if pv belongs to existing vg
vgcreate $vg1 $dev1 $dev3
vgcreate $vg2 $dev2
not vgextend $vg2 $dev3
vgremove -f $vg1
vgremove -f $vg2
pvremove -f $dev1 $dev2 $dev3
#vgextend fails if vg is not resizeable
vgcreate $vg1 $dev1 $dev2
vgchange --resizeable n $vg1
not vgextend $vg1 $dev3
vgremove -f $vg1
pvremove -f $dev1 $dev2
# all PVs exist in the VG after extended
pvcreate $dev1
vgcreate $vg1 $dev2
vgextend $vg1 $dev1 $dev3
check_pv_field_ $dev1 vg_name $vg1
check_pv_field_ $dev2 vg_name $vg1
check_pv_field_ $dev3 vg_name $vg1
vgremove -f $vg1
pvremove -f $dev1 $dev2 $dev3
Update nightly tests for vgextend --metadataignore.
2010-06-30 17:04:59 +04:00
echo test vgextend --metadataignore
for mdacp in 1 2; do
for ignore in y n; do
echo vgextend --metadataignore has proper mda_count and mda_used_count
vgcreate $vg $dev3
vgextend --metadataignore $ignore --pvmetadatacopies $mdacp $vg $dev1 $dev2
check_pv_field_ $dev1 pv_mda_count $mdacp
check_pv_field_ $dev2 pv_mda_count $mdacp
if [ $ignore = y ]; then
check_pv_field_ $dev1 pv_mda_used_count 0
check_pv_field_ $dev2 pv_mda_used_count 0
else
check_pv_field_ $dev1 pv_mda_used_count $mdacp
check_pv_field_ $dev2 pv_mda_used_count $mdacp
fi
echo vg has proper vg_mda_count and vg_mda_used_count
check_vg_field_ $vg vg_mda_count $(($mdacp * 2 + 1))
if [ $ignore = y ]; then
check_vg_field_ $vg vg_mda_used_count 1
else
check_vg_field_ $vg vg_mda_used_count $(($mdacp * 2 + 1))
fi
check_vg_field_ $vg vg_mda_copies unmanaged
vgremove $vg
pvremove -ff $dev1 $dev2 $dev3
done
done
Copy Permalink