1
0
mirror of git://sourceware.org/git/lvm2.git synced 2024-12-22 17:35:59 +03:00
lvm2/man/pvmove.8.in

188 lines
6.7 KiB
Groff
Raw Normal View History

.TH PVMOVE 8 "LVM TOOLS #VERSION#" "Sistina Software UK" \" -*- nroff -*-
2003-04-30 19:24:08 +04:00
.SH NAME
pvmove \(em move physical extents
2003-04-30 19:24:08 +04:00
.SH SYNOPSIS
.B pvmove
.RB [ \-\-abort ]
.RB [ \-\-alloc
.IR AllocationPolicy ]
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
.RB [ \-\-atomic ]
.RB [ \-b | \-\-background ]
.RB [ \-\-commandprofile
.IR ProfileName ]
.RB [ \-d | \-\-debug ]
.RB [ \-h | \-\-help ]
.RB [ \-i | \-\-interval
.IR Seconds ]
.RB [ \-\-noudevsync ]
.RB [ \-\-reportformat
.RB { basic | json }]
.RB [ \-v | \-\-verbose ]
.RB [ \-n | \-\-name
.IR LogicalVolume ]
.RI [ SourcePhysicalVolume [ :PE [ \-PE ]...]
.RI [ DestinationPhysicalVolume [ :PE [ \-PE ]...]...]]
2003-04-30 19:24:08 +04:00
.SH DESCRIPTION
pvmove allows you to move the allocated physical extents (PEs) on
2003-04-30 19:24:08 +04:00
.I SourcePhysicalVolume
to one or more other physical volumes (PVs).
You can optionally specify a source
.I LogicalVolume
in which case only extents used by that LV will be moved to
free (or specified) extents on
.IR DestinationPhysicalVolume (s).
If no
.I DestinationPhysicalVolume
is specified, the normal allocation rules for the Volume Group are used.
2003-04-30 19:24:08 +04:00
If pvmove gets interrupted for any reason (e.g. the machine crashes)
then run pvmove again without any PhysicalVolume arguments to
2004-09-14 17:58:11 +04:00
restart any moves that were in progress from the last checkpoint.
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
Alternatively use \fBpvmove \-\-abort\fP at any time to abort. The
resulting location of logical volumes after an abort is issued depends
on whether the
.B \-\-atomic
option was used when starting the pvmove process.
2004-09-14 17:58:11 +04:00
You can run more than one pvmove at once provided they are moving data
off different SourcePhysicalVolumes, but additional pvmoves will ignore
any Logical Volumes already in the process of being changed, so some
2004-09-14 17:58:11 +04:00
data might not get moved.
\fBpvmove\fP works as follows:
1. A temporary 'pvmove' Logical Volume is created to store
2004-09-14 17:58:11 +04:00
details of all the data movements required.
2. Every Logical Volume in the Volume Group is searched
2004-09-14 17:58:11 +04:00
for contiguous data that need moving
according to the command line arguments.
For each piece of data found, a new segment is added to the end of the
pvmove LV.
This segment takes the form of a temporary mirror to copy the data
from the original location to a newly-allocated location.
The original LV is updated to use the new temporary mirror segment
in the pvmove LV instead of accessing the data directly.
3. The Volume Group metadata is updated on disk.
2004-09-14 17:58:11 +04:00
4. The first segment of the pvmove Logical Volume is activated and starts
2004-09-14 17:58:11 +04:00
to mirror the first part of the data. Only one segment is mirrored at once
as this is usually more efficient.
5. A daemon repeatedly checks progress at the specified time interval.
When it detects that the first temporary mirror is in-sync,
it breaks that mirror so that only the new location for that data gets used
and writes a checkpoint into the Volume Group metadata on disk.
2004-09-14 17:58:11 +04:00
Then it activates the mirror for the next segment of the pvmove LV.
6. When there are no more segments left to be mirrored,
the temporary Logical Volume is removed and the Volume Group metadata
is updated so that the Logical Volumes reflect the new data locations.
2004-09-14 17:58:11 +04:00
Note that this new process cannot support the original LVM1
type of on-disk metadata. Metadata can be converted using \fBvgconvert\fP(8).
2003-04-30 19:24:08 +04: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
If the
.B \-\-atomic
option is used, a slightly different approach is used for the move. Again,
a temporary 'pvmove' logical volume is created to store the details of all
the data movements required. This temporary LV contains all the segments of
the various LVs that need to be moved. However this time, an identical
logical volume is allocated that contains the same number of segments and
a mirror is created to copy the contents from the first temporary LV to the
second. When a complete copy is accomplished, the temporary logical volumes
are removed, leaving behind the segments on the destination physical volume.
If an abort is issued during the move, all logical volumes being moved will
remain on the source physical volume.
2003-04-30 19:24:08 +04:00
.SH OPTIONS
See \fBlvm\fP(8) for common options.
2003-04-30 19:24:08 +04:00
.TP
.B \-\-abort
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
Abort any moves in progress. If the
.B \-\-atomic
option was used to start the pvmove, all logical volumes will remain on
the source physical volume. Otherwise, those segments that have completed
the move will stay on the destination physical volume, while those that
have not will remain on the source physical volume.
.TP
.B \-\-atomic
Make the entire operation atomic. That is, ensure that all affected logical
volumes are moved to the destination physical volume together; unless the move
has been aborted. If the move has been aborted, all logical volumes will
remain on the source physical volume.
2004-09-14 17:58:11 +04:00
.TP
.B \-\-noudevsync
Disable udev synchronisation. The
process will not wait for notification from udev.
It will continue irrespective of any possible udev processing
in the background. You should only use this if udev is not running
or has rules that ignore the devices LVM2 creates.
.TP
.BR \-b ", " \-\-background
2004-09-14 17:58:11 +04:00
Run the daemon in the background.
2003-07-18 04:41:04 +04:00
.TP
.BR \-i ", " \-\-interval " " \fISeconds
2003-04-30 19:24:08 +04:00
Report progress as a percentage at regular intervals.
.TP
.BR \-n ", " \-\-name " " \fILogicalVolume
2003-04-30 19:24:08 +04:00
Move only the extents belonging to
.I LogicalVolume
from
.I SourcePhysicalVolume
instead of all allocated extents to the destination physical volume(s).
.SH Examples
To move all Physical Extents that are used by simple Logical Volumes on
/dev/sdb1 to free Physical Extents elsewhere in the Volume Group use:
2003-04-30 19:24:08 +04:00
.sp
.B pvmove /dev/sdb1
2011-02-10 01:24:55 +03:00
.P
Additionally, a specific destination device /dev/sdc1
can be specified like this:
.sp
.B pvmove /dev/sdb1 /dev/sdc1
2011-02-10 01:24:55 +03:00
.P
To perform the action only on extents belonging to the single Logical Volume
lvol1 do this:
2011-02-10 01:24:55 +03:00
.sp
.B pvmove \-n lvol1 /dev/sdb1 /dev/sdc1
2011-02-10 01:24:55 +03:00
.P
Rather than moving the contents of the entire device, it is possible to
move a range of Physical Extents - for example numbers 1000 to 1999
inclusive on /dev/sdb1 - like this:
2011-02-10 01:24:55 +03:00
.sp
.B pvmove /dev/sdb1:1000\-1999
2011-02-10 01:24:55 +03:00
.P
A range can also be specified as start+length, so
.sp
.B pvmove /dev/sdb1:1000+1000
.P
also refers to 1000 Physical Extents starting from Physical Extent number 1000.
(Counting starts from 0, so this refers to the 1001st to the 2000th inclusive.)
.P
To move a range of Physical Extents to a specific location (which must have
2013-12-17 22:26:10 +04:00
sufficient free extents) use the form:
2011-02-10 01:24:55 +03:00
.sp
.B pvmove /dev/sdb1:1000\-1999 /dev/sdc1
2011-02-10 01:24:55 +03:00
.sp
or
.sp
.B pvmove /dev/sdb1:1000\-1999 /dev/sdc1:0\-999
2011-02-10 01:24:55 +03:00
.P
If the source and destination are on the same disk, the
.B anywhere
allocation policy would be needed, like this:
.sp
.B pvmove \-\-alloc anywhere /dev/sdb1:1000\-1999 /dev/sdb1:0\-999
.P
The part of a specific Logical Volume present within in a range of Physical
Extents can also be picked out and moved, like this:
2011-02-10 01:24:55 +03:00
.sp
.B pvmove \-n lvol1 /dev/sdb1:1000\-1999 /dev/sdc1
2003-04-30 19:24:08 +04:00
.SH SEE ALSO
.BR lvm (8),
.BR vgconvert (8)
.BR pvs (8)