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
361e2d8df7
lvm2/test/shell/pvmove-basic.sh

362 lines
10 KiB
Bash
Raw Normal View History

Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
#!/bin/sh
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
# Copyright (C) 2008-2013 Red Hat, Inc. All rights reserved.
Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
# Copyright (C) 2007 NEC Corporation
#
# 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
test_description="ensure that pvmove works with basic options"
tests: rename test to inittest We are getting into problem when we use 'test' for commands like should/not/... So avoid overloading test name and change it to inittest.
2014-06-06 19:40:04 +04:00
. lib/inittest
Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
Speedup test run by a few minutes Reduce disc excercise for some test and focus on LVM testing by using smaller extent size. Reduce number of teardown_devs calls and use vg/lvremove instead. Don't sleep for seconds on pvmove. FIXME: shell/lvconvert-mirror-basic.sh seems to need more checking. Test fails for smalled extent size then 512k.
2012-03-04 20:02:19 +04:00
which md5sum || skip
test: Disable lvmetad debug log on another bunch of tests.
2014-10-01 10:31:53 +04:00
# disable lvmetad logging as it bogs down test systems
test -e LOCAL_LVMETAD && aux prepare_lvmetad ""
Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
# ---------------------------------------------------------------------
# Utilities
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
create_vg_() {
vgcreate -c n -s 128k $vg $(cat DEVICES)
Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
}
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
# ---------------------------------------------------------------------
# Common environment setup/cleanup for each sub testcases
prepare_lvs_() {
lvcreate -l2 -n $lv1 $vg "$dev1"
check lv_on $vg $lv1 "$dev1"
lvcreate -l9 -i3 -n $lv2 $vg "$dev2" "$dev3" "$dev4"
check lv_on $vg $lv2 "$dev2" "$dev3" "$dev4"
lvextend -l+2 $vg/$lv1 "$dev2"
check lv_on $vg $lv1 "$dev1" "$dev2"
lvextend -l+2 $vg/$lv1 "$dev3"
lvextend -l+2 $vg/$lv1 "$dev1"
check lv_on $vg $lv1 "$dev1" "$dev2" "$dev3"
lvcreate -l1 -n $lv3 $vg "$dev2"
check lv_on $vg $lv3 "$dev2"
aux mkdev_md5sum $vg $lv1
aux mkdev_md5sum $vg $lv2
aux mkdev_md5sum $vg $lv3
get lv_devices "$vg/$lv1" > "${lv1}_devs"
get lv_devices "$vg/$lv2" > "${lv2}_devs"
get lv_devices "$vg/$lv3" > "${lv3}_devs"
lvs -a -o name,size,seg_pe_ranges $vg
vgcfgbackup -f bak-$$ $vg
Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
}
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
# Restore metadata content, since data are pvmove-ed
# original content should be preserved
restore_lvs_() {
vgcfgrestore -f bak-$$ $vg
vgchange -ay $vg
Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
}
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
lvs_not_changed_() {
for i in "${@}"; do
get lv_devices "$vg/$i" | tee out
diff "${i}_devs" out || \
(cat "${i}_devs"; die "Devices for LV $vg/$i differs!")
done
Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
}
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check_and_cleanup_lvs_() {
check dev_md5sum $vg $lv1
check dev_md5sum $vg $lv2
check dev_md5sum $vg $lv3
get lv_field $vg name >out
not grep ^pvmove out
vgchange -an $vg
lvremove -ff $vg
(dm_table | not grep $vg) || \
test: Clean-up pvmove-basic for atomic pvmove test The way I was testing for the existence of pvmove mimages was incorrect for rhel5. This patch makes it more generic/universal.
2014-06-19 00:40:06 +04:00
die "ERROR: lvremove did leave some mappings in DM behind!"
Speedup test run by a few minutes Reduce disc excercise for some test and focus on LVM testing by using smaller extent size. Reduce number of teardown_devs calls and use vg/lvremove instead. Don't sleep for seconds on pvmove. FIXME: shell/lvconvert-mirror-basic.sh seems to need more checking. Test fails for smalled extent size then 512k.
2012-03-04 20:02:19 +04:00
}
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
# ---------------------------------------------------------------------
# Initialize PVs and VGs
Speedup test run by a few minutes Reduce disc excercise for some test and focus on LVM testing by using smaller extent size. Reduce number of teardown_devs calls and use vg/lvremove instead. Don't sleep for seconds on pvmove. FIXME: shell/lvconvert-mirror-basic.sh seems to need more checking. Test fails for smalled extent size then 512k.
2012-03-04 20:02:19 +04:00
aux prepare_pvs 5 5
create_vg_
Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
for mode in "--atomic" ""
do
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
#COMM "check environment setup/cleanup"
prepare_lvs_
check_and_cleanup_lvs_
Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
# ---------------------------------------------------------------------
# pvmove tests
# ---
# filter by LV
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
#COMM "only specified LV is moved: from pv2 to pv5 only for lv1"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i1 -n $vg/$lv1 "$dev2" "$dev5"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check lv_on $vg $lv1 "$dev1" "$dev5" "$dev3"
lvs_not_changed_ $lv2 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
# ---
# segments in a LV
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
#COMM "the 1st seg of 3-segs LV is moved: from pv1 of lv1 to pv4"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i0 -n $vg/$lv1 "$dev1" "$dev4"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check lv_on $vg $lv1 "$dev4" "$dev2" "$dev3"
lvs_not_changed_ $lv2 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
#COMM "the 2nd seg of 3-segs LV is moved: from pv2 of lv1 to pv4"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i0 -n $vg/$lv1 "$dev2" "$dev4"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check lv_on $vg $lv1 "$dev1" "$dev4" "$dev3"
lvs_not_changed_ $lv2 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
#COMM "the 3rd seg of 3-segs LV is moved: from pv3 of lv1 to pv4"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i0 -n $vg/$lv1 "$dev3" "$dev4"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check lv_on $vg $lv1 "$dev1" "$dev2" "$dev4"
lvs_not_changed_ $lv2 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
# ---
# multiple LVs matching
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
#COMM "1 out of 3 LVs is moved: from pv4 to pv5"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i0 "$dev4" "$dev5"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check lv_on $vg $lv2 "$dev2" "$dev3" "$dev5"
lvs_not_changed_ $lv1 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
#COMM "2 out of 3 LVs are moved: from pv3 to pv5"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i0 "$dev3" "$dev5"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check lv_on $vg $lv1 "$dev1" "$dev2" "$dev5"
check lv_on $vg $lv2 "$dev2" "$dev5" "$dev4"
lvs_not_changed_ $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
#COMM "3 out of 3 LVs are moved: from pv2 to pv5"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i0 "$dev2" "$dev5"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check lv_on $vg $lv1 "$dev1" "$dev5" "$dev3"
check lv_on $vg $lv2 "$dev5" "$dev3" "$dev4"
check lv_on $vg $lv3 "$dev5"
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
# ---
# areas of striping
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
#COMM "move the 1st stripe: from pv2 of lv2 to pv1"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i0 -n $vg/$lv2 "$dev2" "$dev1"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check lv_on $vg $lv2 "$dev1" "$dev3" "$dev4"
lvs_not_changed_ $lv1 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
#COMM "move the 2nd stripe: from pv3 of lv2 to pv1"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i0 -n $vg/$lv2 "$dev3" "$dev1"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check lv_on $vg $lv2 "$dev2" "$dev1" "$dev4"
lvs_not_changed_ $lv1 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
#COMM "move the 3rd stripe: from pv4 of lv2 to pv1"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i0 -n $vg/$lv2 "$dev4" "$dev1"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check lv_on $vg $lv2 "$dev2" "$dev3" "$dev1"
lvs_not_changed_ $lv1 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
# ---
# partial segment match (source segment splitted)
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
#COMM "match to the start of segment:from pv2:0-0 to pv5"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i0 "$dev2":0-0 "$dev5"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check lv_on $vg $lv2 "$dev5" "$dev2" "$dev3" "$dev4"
lvs_not_changed_ $lv1 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
#exit 0
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
#COMM "match to the middle of segment: from pv2:1-1 to pv5"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i0 "$dev2":1-1 "$dev5"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check lv_on $vg $lv2 "$dev2" "$dev3" "$dev4" "$dev5"
lvs_not_changed_ $lv1 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
#COMM "match to the end of segment: from pv2:2-2 to pv5"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i0 "$dev2":2-2 "$dev5"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check lv_on $vg $lv2 "$dev2" "$dev5" "$dev3" "$dev4"
lvs_not_changed_ $lv1 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
# ---
# destination segment splitted
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
#COMM "no destination split: from pv2:0-2 to pv5"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i0 "$dev2":0-2 "$dev5"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check lv_on $vg $lv2 "$dev5" "$dev3" "$dev4"
lvs_not_changed_ $lv1 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
#COMM "destination split into 2: from pv2:0-2 to pv5:5-5 and pv4:5-6"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i0 --alloc anywhere "$dev2":0-2 "$dev5":5-5 "$dev4":5-6
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check lv_on $vg $lv2 "$dev5" "$dev4" "$dev3"
lvs_not_changed_ $lv1 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
#COMM "destination split into 3: from pv2:0-2 to {pv3,4,5}:5-5"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i0 --alloc anywhere "$dev2":0-2 "$dev3":5-5 "$dev4":5-5 "$dev5":5-5
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check lv_on $vg $lv2 "$dev3" "$dev4" "$dev5"
lvs_not_changed_ $lv1 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
# ---
# alloc policy (anywhere, contiguous) with both success and failure cases
Update tests Indent Shell improvements - use internal function for checks Use PVs in "" (LV and VG cannot have spaces) Several test very starting 'dmeventd' without annoucing it via prepade_dmeventd. Fix some of test actually.
2012-03-16 17:00:05 +04:00
#COMM "alloc normal on same PV for source and destination: from pv3:0-2 to pv3:5-7"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
not pvmove $mode -i0 "$dev3":0-2 "$dev3":5-7
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
# "(cleanup previous test)"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
lvs_not_changed_ $lv1 $lv2 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
#COMM "alloc anywhere on same PV for source and destination: from pv3:0-2 to pv3:5-7"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i0 --alloc anywhere "$dev3":0-2 "$dev3":5-7
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check lv_on $vg $lv2 "$dev2" "$dev3" "$dev4"
lvs_not_changed_ $lv1 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
#COMM "alloc anywhere but better area available: from pv3:0-2 to pv3:5-7 or pv5:5-6,pv4:5-5"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
#lvs -a -o name,size,seg_pe_ranges $vg
#LV2 1.12m @TESTDIR@/dev/mapper/@PREFIX@pv2:0-2 @TESTDIR@/dev/mapper/@PREFIX@pv3:0-2 @TESTDIR@/dev/mapper/@PREFIX@pv4:0-2
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i0 --alloc anywhere "$dev3":0-2 "$dev3":5-7 "$dev5":5-6 "$dev4":5-5
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
#lvs -a -o name,size,seg_pe_ranges $vg
# Hmm is this correct ? - why pv2 is split
#LV2 1.12m @TESTDIR@/dev/mapper/@PREFIX@pv2:0-1 @TESTDIR@/dev/mapper/@PREFIX@pv5:5-6 @TESTDIR@/dev/mapper/@PREFIX@pv4:0-1
#LV2 1.12m @TESTDIR@/dev/mapper/@PREFIX@pv2:2-2 @TESTDIR@/dev/mapper/@PREFIX@pv3:5-5 @TESTDIR@/dev/mapper/@PREFIX@pv4:2-2
check lv_on $vg $lv2 "$dev2" "$dev3" "$dev4" "$dev5"
lvs_not_changed_ $lv1 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
#COMM "alloc contiguous but area not available: from pv2:0-2 to pv5:5-5 and pv4:5-6"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
not pvmove $mode -i0 --alloc contiguous "$dev2":0-2 "$dev5":5-5 "$dev4":5-6
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
# "(cleanup previous test)"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
lvs_not_changed_ $lv1 $lv2 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
#COMM "alloc contiguous and contiguous area available: from pv2:0-2 to pv5:0-0,pv5:3-5 and pv4:5-6"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i0 --alloc contiguous "$dev2":0-2 "$dev5":0-0 "$dev5":3-5 "$dev4":5-6
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check lv_on $vg $lv2 "$dev5" "$dev3" "$dev4"
lvs_not_changed_ $lv1 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
# ---
# multiple segments in a LV
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
#COMM "multiple source LVs: from pv3 to pv5"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i0 "$dev3" "$dev5"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check lv_on $vg $lv1 "$dev1" "$dev2" "$dev5"
check lv_on $vg $lv2 "$dev2" "$dev5" "$dev4"
lvs_not_changed_ $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
# ---
# move inactive LV
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
#COMM "move inactive LV: from pv2 to pv5"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
Update tests Indent Shell improvements - use internal function for checks Use PVs in "" (LV and VG cannot have spaces) Several test very starting 'dmeventd' without annoucing it via prepade_dmeventd. Fix some of test actually.
2012-03-16 17:00:05 +04:00
lvchange -an $vg/$lv1
lvchange -an $vg/$lv3
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i0 "$dev2" "$dev5"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check lv_on $vg $lv1 "$dev1" "$dev5" "$dev3"
check lv_on $vg $lv2 "$dev5" "$dev3" "$dev4"
check lv_on $vg $lv3 "$dev5"
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
# ---
# other failure cases
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
#COMM "no PEs to move: from pv3 to pv1"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i0 "$dev3" "$dev1"
not pvmove $mode -i0 "$dev3" "$dev1"
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
# "(cleanup previous test)"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
check lv_on $vg $lv1 "$dev1" "$dev2" "$dev1"
check lv_on $vg $lv2 "$dev2" "$dev1" "$dev4"
lvs_not_changed_ $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
Update tests Indent Shell improvements - use internal function for checks Use PVs in "" (LV and VG cannot have spaces) Several test very starting 'dmeventd' without annoucing it via prepade_dmeventd. Fix some of test actually.
2012-03-16 17:00:05 +04:00
#COMM "no space available: from pv2:0-0 to pv1:0-0"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
not pvmove $mode -i0 "$dev2":0-0 "$dev1":0-0
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
# "(cleanup previous test)"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
lvs_not_changed_ $lv1 $lv2 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
#COMM 'same source and destination: from pv1 to pv1'
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
not pvmove $mode -i0 "$dev1" "$dev1"
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
#"(cleanup previous test)"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
lvs_not_changed_ $lv1 $lv2 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
#COMM "sum of specified destination PEs is large enough, but it includes source PEs and the free PEs are not enough"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
not pvmove $mode --alloc anywhere "$dev1":0-2 "$dev1":0-2 "$dev5":0-0 2> err
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
#"(cleanup previous test)"
Update tests Indent Shell improvements - use internal function for checks Use PVs in "" (LV and VG cannot have spaces) Several test very starting 'dmeventd' without annoucing it via prepade_dmeventd. Fix some of test actually.
2012-03-16 17:00:05 +04:00
grep "Insufficient free space" err
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
lvs_not_changed_ $lv1 $lv2 $lv3
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
# ---------------------------------------------------------------------
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
#COMM "pvmove abort"
tests: enhance pvmove testing Rewrite check lv_on and add new lv_tree_on Move more pvmove test unrelated code out to check & get sections (so they do not obfuscate trace output unnecesserily) Use new lv_tree_on() NOTE: unsure how the snapshot origin should be accounted here. Split pmove-all-segments into separate tests for raid and thins (so the test output properly shows what has been skipped in test)
2013-09-16 13:18:31 +04:00
restore_lvs_
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode -i100 -b "$dev1" "$dev3"
Update tests Indent Shell improvements - use internal function for checks Use PVs in "" (LV and VG cannot have spaces) Several test very starting 'dmeventd' without annoucing it via prepade_dmeventd. Fix some of test actually.
2012-03-16 17:00:05 +04:00
pvmove --abort
More test conversions by jstava. Make check still passes.
2008-10-06 20:47:07 +04:00
check_and_cleanup_lvs_
Fix 'make check' runnable with recent versions of dmsetup. Fix 'make check' to use DMDIR to check DM_DEV_DIR support in dmsetup. Add basic test cases for mirrored LV. Add basic test cases for lvconvert mirror. Add basic test cases for pvmove. Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Add new vgsplit and vgmerge tests. Dave Wysochanski <dwysocha@redhat.com>
2008-01-17 00:21:22 +03:00
add bz264241 check remove lvconvert progress notifications (-i100) (by jstava)
2008-11-10 15:41:52 +03:00
#COMM "pvmove out of --metadatacopies 0 PV (bz252150)"
vgremove -ff $vg
Substantial rework of the functional test support code. Some new features: - somewhat neater, more consistent and more readable output - possible to set any lvm.conf value: aux lvmconf "section/key = value" - LVM_TEST_NODEBUG to suppress the (lengthy) "## DEBUG" output - back-substitution on test output ($TESTDIR/$PREFIX -> @TESTDIR@/@PREFIX@) - support code moved from test/ to test/lib/ --> less clutter
2011-01-05 03:16:18 +03:00
pvcreate $(cat DEVICES)
Update tests Indent Shell improvements - use internal function for checks Use PVs in "" (LV and VG cannot have spaces) Several test very starting 'dmeventd' without annoucing it via prepade_dmeventd. Fix some of test actually.
2012-03-16 17:00:05 +04:00
pvcreate --metadatacopies 0 "$dev1" "$dev2"
Speedup test run by a few minutes Reduce disc excercise for some test and focus on LVM testing by using smaller extent size. Reduce number of teardown_devs calls and use vg/lvremove instead. Don't sleep for seconds on pvmove. FIXME: shell/lvconvert-mirror-basic.sh seems to need more checking. Test fails for smalled extent size then 512k.
2012-03-04 20:02:19 +04:00
create_vg_
Update tests Indent Shell improvements - use internal function for checks Use PVs in "" (LV and VG cannot have spaces) Several test very starting 'dmeventd' without annoucing it via prepade_dmeventd. Fix some of test actually.
2012-03-16 17:00:05 +04:00
lvcreate -l4 -n $lv1 $vg "$dev1"
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
pvmove $mode "$dev1"
add bz264241 check remove lvconvert progress notifications (-i100) (by jstava)
2008-11-10 15:41:52 +03:00
If pvmove fails activating mirror volume, try restore to previous state. pvmove now keep suspended devices if temporary mirror creation fails. We can try to restore previous state if it is first attempt to activate pvmove (code basically run the same code as --abort automatically).
2009-05-19 13:51:02 +04:00
#COMM "pvmove fails activating mirror, properly restores state before pvmove"
Update tests Indent Shell improvements - use internal function for checks Use PVs in "" (LV and VG cannot have spaces) Several test very starting 'dmeventd' without annoucing it via prepade_dmeventd. Fix some of test actually.
2012-03-16 17:00:05 +04:00
dmsetup create $vg-pvmove0 --notable
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
not pvmove $mode -i 1 "$dev2"
dmsetup info --noheadings -c -o suspended $vg-$lv1
Update tests Indent Shell improvements - use internal function for checks Use PVs in "" (LV and VG cannot have spaces) Several test very starting 'dmeventd' without annoucing it via prepade_dmeventd. Fix some of test actually.
2012-03-16 17:00:05 +04:00
test $(dmsetup info --noheadings -c -o suspended $vg-$lv1) = "Active"
test: Clean-up pvmove-basic for atomic pvmove test The way I was testing for the existence of pvmove mimages was incorrect for rhel5. This patch makes it more generic/universal.
2014-06-19 00:40:06 +04:00
if dmsetup info $vg-pvmove0_mimage_0 > /dev/null; then
dmsetup remove $vg-pvmove0 $vg-pvmove0_mimage_0 $vg-pvmove0_mimage_1
pvmove: Enable all-or-nothing (atomic) pvmoves pvmove can be used to move single LVs by name or multiple LVs that lie within the specified PV range (e.g. /dev/sdb1:0-1000). When moving more than one LV, the portions of those LVs that are in the range to be moved are added to a new temporary pvmove LV. The LVs then point to the range in the pvmove LV, rather than the PV range. Example 1: We have two LVs in this example. After they were created, the first LV was grown, yeilding two segments in LV1. So, there are two LVs with a total of three segments. Before pvmove: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- After pvmove inserts the temporary pvmove LV: --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | ------------------------------------- PV | 000 - 255 | 256 - 511 | 512 - 767 | ------------------------------------- Each of the affected LV segments now point to a range of blocks in the pvmove LV, which purposefully corresponds to the segments moved from the original LVs into the temporary pvmove LV. The current implementation goes on from here to mirror the temporary pvmove LV by segment. Further, as the pvmove LV is activated, only one of its segments is actually mirrored (i.e. "moving") at a time. The rest are either complete or not addressed yet. If the pvmove is aborted, those segments that are completed will remain on the destination and those that are not yet addressed or in the process of moving will stay on the source PV. Thus, it is possible to have a partially completed move - some LVs (or certain segments of LVs) on the source PV and some on the destination. Example 2: What 'example 1' might look if it was half-way through the move. --------- --------- --------- | LV1s0 | | LV2s0 | | LV1s1 | --------- --------- --------- | | | ------------------------------------- pvmove0 | seg 0 | seg 1 | seg 2 | ------------------------------------- | | | | ------------------------- source PV | | 256 - 511 | 512 - 767 | | ------------------------- | || ------------------------- dest PV | 000 - 255 | 256 - 511 | ------------------------- This update allows the user to specify that they would like the pvmove mirror created "by LV" rather than "by segment". That is, the pvmove LV becomes an image in an encapsulating mirror along with the allocated copy image. Example 3: A pvmove that is performed "by LV" rather than "by segment". --------- --------- | LV1s0 | | LV2s0 | --------- --------- | | ------------------------- pvmove0 | * LV-level mirror * | ------------------------- / \ pvmove_mimage0 / pvmove_mimage1 ------------------------- ------------------------- | seg 0 | seg 1 | | seg 0 | seg 1 | ------------------------- ------------------------- | | | | ------------------------- ------------------------- | 000 - 255 | 256 - 511 | | 000 - 255 | 256 - 511 | ------------------------- ------------------------- source PV dest PV The thing that differentiates a pvmove done in this way and a simple "up-convert" from linear to mirror is the preservation of the distinct segments. A normal up-convert would simply allocate the necessary space with no regard for segment boundaries. The pvmove operation must preserve the segments because they are the critical boundary between the segments of the LVs being moved. So, when the pvmove copy image is allocated, all corresponding segments must be allocated. The code that merges ajoining segments that are part of the same LV when the metadata is written must also be avoided in this case. This method of mirroring is unique enough to warrant its own definitional macro, MIRROR_BY_SEGMENTED_LV. This joins the two existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV (for user created mirrors). The advantages of performing pvmove in this way is that all of the LVs affected can be moved together. It is an all-or-nothing approach that leaves all LV segments on the source PV if the move is aborted. Additionally, a mirror log can be used (in the future) to provide tracking of progress; allowing the copy to continue where it left off in the event there is a deactivation.
2014-06-18 07:59:36 +04:00
else
dmsetup remove $vg-pvmove0
fi
lvremove -ff $vg
test: Disable lvmetad debug log on another bunch of tests.
2014-10-01 10:31:53 +04:00
done
Copy Permalink