[lvm2.git] / doc / pvmove_outline.txt

Let's say we have an LV, made up of three segments of different PV's,
I've also added in the device major:minor as this will be useful
later:

+-----------------------------+
|  PV1     |   PV2   |   PV3  | 254:3
+----------+---------+--------+


Now our hero decides to PV move PV2 to PV4:

1. Suspend our LV (254:3), this starts queueing all io, and flushes
   all pending io.  Once the suspend has completed we are free to change
   the mapping table.

2. Set up *another* (254:4) device with the mapping table of our LV.

3. Load a new mapping table into (254:3) that has identity targets for
   parts that aren't moving, and a mirror target for parts that are.

4. Unsuspend (254:3)

So now we have:
                           destination of copy
               +--------------------->--------------+
               |                                    |
+-----------------------------+               + -----------+
| Identity | mirror  | Ident. | 254:3         |    PV4     |
+----------+---------+--------+               +------------+
     |         |         |
     \/        \/        \/
+-----------------------------+
|  PV1     |   PV2   |   PV3  | 254:4
+----------+---------+--------+

Any writes to segment2 of the LV get intercepted by the mirror target
who checks that that chunk has been copied to the new destination, if
it hasn't it queues the initial copy and defers the current io until
it has finished.  Then the current io is written to *both* PV2 and the
PV4.

5. When the copying has completed 254:3 is suspended/pending flushed.

6. 254:4 is taken down

7. metadata is updated on disk

8. 254:3 has new mapping table loaded:

+-----------------------------+
|  PV1     |   PV4   |   PV3  | 254:3
+----------+---------+--------+
Commit	Line	Data
39742324 JT	1	Let's say we have an LV, made up of three segments of different PV's,
	2	I've also added in the device major:minor as this will be useful
	3	later:
	4
	5	+-----------------------------+
	6	\| PV1 \| PV2 \| PV3 \| 254:3
	7	+----------+---------+--------+
	8
	9
	10	Now our hero decides to PV move PV2 to PV4:
	11
	12	1. Suspend our LV (254:3), this starts queueing all io, and flushes
	13	all pending io. Once the suspend has completed we are free to change
	14	the mapping table.
	15
	16	2. Set up another (254:4) device with the mapping table of our LV.
	17
	18	3. Load a new mapping table into (254:3) that has identity targets for
	19	parts that aren't moving, and a mirror target for parts that are.
	20
	21	4. Unsuspend (254:3)
	22
	23	So now we have:
	24	destination of copy
	25	+--------------------->--------------+
	26	\| \|
	27	+-----------------------------+ + -----------+
	28	\| Identity \| mirror \| Ident. \| 254:3 \| PV4 \|
	29	+----------+---------+--------+ +------------+
	30	\| \| \|
	31	\/ \/ \/
	32	+-----------------------------+
aa5c5673	33	\| PV1 \| PV2 \| PV3 \| 254:4
39742324 JT	34	+----------+---------+--------+
	35
	36	Any writes to segment2 of the LV get intercepted by the mirror target
	37	who checks that that chunk has been copied to the new destination, if
	38	it hasn't it queues the initial copy and defers the current io until
	39	it has finished. Then the current io is written to both PV2 and the
	40	PV4.
	41
	42	5. When the copying has completed 254:3 is suspended/pending flushed.
	43
	44	6. 254:4 is taken down
	45
	46	7. metadata is updated on disk
	47
	48	8. 254:3 has new mapping table loaded:
	49
	50	+-----------------------------+
	51	\| PV1 \| PV4 \| PV3 \| 254:3
	52	+----------+---------+--------+