mirror of
git://sourceware.org/git/lvm2.git
synced 2025-01-03 05:18:29 +03:00
62 lines
2.9 KiB
Plaintext
62 lines
2.9 KiB
Plaintext
pvmove moves the allocated physical extents (PEs) on a source PV to one or
|
|
more destination PVs. You can optionally specify a source LV in which
|
|
case only extents used by that LV will be moved to free (or specified)
|
|
extents on the destination PV. If no destination PV is specified, the
|
|
normal allocation rules for the VG are used.
|
|
|
|
If pvmove is interrupted for any reason (e.g. the machine crashes) then
|
|
run pvmove again without any PV arguments to restart any operations that
|
|
were in progress from the last checkpoint. Alternatively, use the abort
|
|
option at any time to abort the operation. The resulting location of LVs
|
|
after an abort depends on whether the atomic option was used.
|
|
|
|
More than one pvmove can run concurrently if they are moving data from
|
|
different source PVs, but additional pvmoves will ignore any LVs already
|
|
in the process of being changed, so some data might not get moved.
|
|
|
|
pvmove works as follows:
|
|
|
|
1. A temporary 'pvmove' LV is created to store details of all the data
|
|
movements required.
|
|
|
|
2. Every LV in the VG is searched 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 VG metadata is updated on disk.
|
|
|
|
4. The first segment of the pvmove LV is activated and starts 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 VG metadata on disk. 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 LV
|
|
is removed and the VG metadata is updated so that the LVs reflect the new
|
|
data locations.
|
|
|
|
Note that this new process cannot support the original LVM1
|
|
type of on-disk metadata. Metadata can be converted using
|
|
\fBvgconvert\fP(8).
|
|
|
|
If the \fB\-\-atomic\fP option is used, a slightly different approach is
|
|
used for the move. Again, a temporary 'pvmove' LV 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, in
|
|
this case, an identical LV 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. After a complete copy is made, the temporary
|
|
LVs are removed, leaving behind the segments on the destination PV. If an
|
|
abort is issued during the move, all LVs being moved will remain on the
|
|
source PV.
|
|
|