1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
|
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.
|
