mirror of
git://sourceware.org/git/lvm2.git
synced 2024-10-28 20:25:52 +03:00
5ebff6cc9f
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.
85 lines
2.6 KiB
Bash
85 lines
2.6 KiB
Bash
#!/bin/sh
|
|
# Copyright (C) 2013 Red Hat, Inc. All rights reserved.
|
|
#
|
|
# This copyrighted material is made available to anyone wishing to use,
|
|
# modify, copy, or redistribute it subject to the terms and conditions
|
|
# of the GNU General Public License v.2.
|
|
#
|
|
# You should have received a copy of the GNU General Public License
|
|
# along with this program; if not, write to the Free Software Foundation,
|
|
# Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
|
|
|
test_description="ensure pvmove works with raid segment types"
|
|
|
|
. lib/inittest
|
|
|
|
test -e LOCAL_CLVMD && skip
|
|
which md5sum || skip
|
|
|
|
aux have_raid 1 3 5 || skip
|
|
|
|
aux prepare_pvs 5 20
|
|
vgcreate -c n -s 128k $vg $(cat DEVICES)
|
|
|
|
for mode in "--atomic" ""
|
|
do
|
|
# Each of the following tests does:
|
|
# 1) Create two LVs - one linear and one other segment type
|
|
# The two LVs will share a PV.
|
|
# 2) Move both LVs together
|
|
# 3) Move only the second LV by name
|
|
|
|
# Testing pvmove of RAID1 LV
|
|
lvcreate -l 2 -n ${lv1}_foo $vg "$dev1"
|
|
lvcreate -l 2 --type raid1 -m 1 -n $lv1 $vg "$dev1" "$dev2"
|
|
check lv_tree_on $vg ${lv1}_foo "$dev1"
|
|
check lv_tree_on $vg $lv1 "$dev1" "$dev2"
|
|
aux mkdev_md5sum $vg $lv1
|
|
pvmove $mode "$dev1" "$dev5"
|
|
check lv_tree_on $vg ${lv1}_foo "$dev5"
|
|
check lv_tree_on $vg $lv1 "$dev2" "$dev5"
|
|
check dev_md5sum $vg $lv1
|
|
pvmove $mode -n $lv1 "$dev5" "$dev4"
|
|
check lv_tree_on $vg $lv1 "$dev2" "$dev4"
|
|
check lv_tree_on $vg ${lv1}_foo "$dev5"
|
|
check dev_md5sum $vg $lv1
|
|
lvremove -ff $vg
|
|
|
|
# Testing pvmove of RAID10 LV
|
|
lvcreate -l 2 -n ${lv1}_foo $vg "$dev1"
|
|
lvcreate -l 4 --type raid10 -i 2 -m 1 -n $lv1 $vg \
|
|
"$dev1" "$dev2" "$dev3" "$dev4"
|
|
check lv_tree_on $vg ${lv1}_foo "$dev1"
|
|
check lv_tree_on $vg $lv1 "$dev1" "$dev2" "$dev3" "$dev4"
|
|
aux mkdev_md5sum $vg $lv1
|
|
pvmove $mode "$dev1" "$dev5"
|
|
check lv_tree_on $vg ${lv1}_foo "$dev5"
|
|
check lv_tree_on $vg $lv1 "$dev2" "$dev3" "$dev4" "$dev5"
|
|
check dev_md5sum $vg $lv1
|
|
pvmove $mode -n $lv1 "$dev5" "$dev1"
|
|
check lv_tree_on $vg $lv1 "$dev1" "$dev2" "$dev3" "$dev4"
|
|
check lv_tree_on $vg ${lv1}_foo "$dev5"
|
|
check dev_md5sum $vg $lv1
|
|
lvremove -ff $vg
|
|
|
|
# Testing pvmove of RAID5 LV
|
|
lvcreate -l 2 -n ${lv1}_foo $vg "$dev1"
|
|
lvcreate -l 4 --type raid5 -i 2 -n $lv1 $vg \
|
|
"$dev1" "$dev2" "$dev3"
|
|
check lv_tree_on $vg ${lv1}_foo "$dev1"
|
|
check lv_tree_on $vg $lv1 "$dev1" "$dev2" "$dev3"
|
|
aux mkdev_md5sum $vg $lv1
|
|
pvmove $mode "$dev1" "$dev5"
|
|
check lv_tree_on $vg ${lv1}_foo "$dev5"
|
|
check lv_tree_on $vg $lv1 "$dev2" "$dev3" "$dev5"
|
|
check dev_md5sum $vg $lv1
|
|
pvmove $mode -n $lv1 "$dev5" "$dev4"
|
|
check lv_tree_on $vg $lv1 "$dev2" "$dev3" "$dev4"
|
|
check lv_tree_on $vg ${lv1}_foo "$dev5"
|
|
check dev_md5sum $vg $lv1
|
|
|
|
lvremove -ff $vg
|
|
done
|
|
|
|
vgremove -ff $vg
|