Squeeze LVM: pvmove failure left with new LVM named /dev/vg0/pvmove0 - Trying to roll back

[Sophie Loewenthal]

Hi everybody,

I am looking for advice on rolling back a failed pvmove of extents on the same PV ( disc ) and appreciate any help.

When trying to create a contiguous set of extents on a disc I accidently moved the wrong extents.

My command was,
pvmove -v /dev/sda3:0-15 /dev/sdc:3028-3043 --alloc anywhere

But should have been,
pvmove -v /dev/sda3:2564-2579 /dev/sdc:3028-3043 --alloc anywhere

You can see I accidentally moved some extents from /boot and perhaps root to the back of the disc.

The command hung, and the server panicked.
I rebooted and the extents appeared as /dev/vg0/pvmove0 in two different locations.

How could I get the root and /boot extents back to the start of the disc safely?

Note my original commands were lost in the Terminal, and not saved in history so the command I used above is from memory… Not ideal.


Kind regard, Soph.

# pvdisplay -m
--- Physical volume ---
PV Name /dev/sda3
VG Name vg0
PV Size 18.80 GiB / not usable 3.88 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 4813
Free PE 112
Allocated PE 4701
PV UUID SEFzt0-E3XH-AOTO-gRpe-SrAB-IF8t-Xtg3xS

--- Physical Segments ---
Physical extent 0 to 15:
Logical volume /dev/vg0/pvmove0
Logical extents 0 to 15
Physical extent 16 to 1279:
Logical volume /dev/vg0/root
Logical extents 16 to 1279
Physical extent 1280 to 1868:
Logical volume /dev/vg0/www
Logical extents 0 to 588
Physical extent 1869 to 2228:
Logical volume /dev/vg0/vmail
Logical extents 1816 to 2175
Physical extent 2229 to 2254:
FREE
Physical extent 2255 to 2318:
Logical volume /dev/vg0/data_owncloud
Logical extents 0 to 63
Physical extent 2319 to 2357:
Logical volume /dev/vg0/vmail
Logical extents 1741 to 1779
Physical extent 2358 to 2418:
Logical volume /dev/vg0/rsnapshot
Logical extents 228 to 288
Physical extent 2419 to 2429:
FREE
Physical extent 2430 to 2478:
Logical volume /dev/vg0/tmp
Logical extents 0 to 48
Physical extent 2479 to 2525:
FREE
Physical extent 2526 to 2559:
Logical volume /dev/vg0/rsnapshot
Logical extents 194 to 227
Physical extent 2560 to 2563:
Logical volume /dev/vg0/cgibin
Logical extents 0 to 3
Physical extent 2564 to 2579:
Logical volume /dev/vg0/varspoolpostfix
Logical extents 0 to 15
Physical extent 2580 to 2615:
Logical volume /dev/vg0/vmail
Logical extents 1780 to 1815
Physical extent 2616 to 2662:
Logical volume /dev/vg0/rsnapshot
Logical extents 147 to 193
Physical extent 2663 to 2815:
Logical volume /dev/vg0/varlog
Logical extents 0 to 152
Physical extent 2816 to 2962:
Logical volume /dev/vg0/rsnapshot
Logical extents 0 to 146
Physical extent 2963 to 3027:
Logical volume /dev/vg0/mysql
Logical extents 0 to 64
Physical extent 3028 to 3043:
Logical volume /dev/vg0/pvmove0
Logical extents 0 to 15
Physical extent 3044 to 3071:
FREE
Physical extent 3072 to 4812:
Logical volume /dev/vg0/vmail
Logical extents 0 to 1740

[Darac Marjal]

On Tue, Mar 01, 2016 at 02:15:14PM +0100, Sophie Loewenthal wrote:
>Hi everybody,
>
>I am looking for advice on rolling back a failed pvmove of extents on the same PV ( disc ) and appreciate any help.
>
> When trying to create a contiguous set of extents on a disc I accidently moved the wrong extents.
>
>My command was,
>pvmove -v /dev/sda3:0-15 /dev/sdc:3028-3043 --alloc anywhere
>
>But should have been,
>pvmove -v /dev/sda3:2564-2579 /dev/sdc:3028-3043 --alloc anywhere
>
>You can see I accidentally moved some extents from /boot and perhaps root to the back of the disc.
>
>The command hung, and the server panicked.
>I rebooted and the extents appeared as /dev/vg0/pvmove0 in two different locations.
>
>How could I get the root and /boot extents back to the start of the disc safely?

Quoting the second paragraph of the pvmove manpage:

If pvmove gets interrupted for any reason (e.g. the machine crashes)
then run pvmove again without any PhysicalVolume arguments to restart
any moves that were in progress from the last checkpoint. Alterna-
tively use pvmove --abort at any time to abort. The resulting location
of logical volumes after an abort is issued depends on whether the
--atomic option was used when starting the pvmove process.


--
For more information, please reread.

[Sophie Loewenthal]

Hi,

Would pvmove —abort roll the changes back?

How would this affect the server, since the earlier pvmove crashed this?

[Stefan Monnier]

> Would pvmove —abort roll the changes back?
> How would this affect the server, since the earlier pvmove crashed this?

pvmove works as follows (more or less):
- allocate the destination.
- configure the destination as a mirror of the source.
- update the new mirror (that's what does the heavy lifting).
- break down the mirroring-connection between the destination and source.
- free the source.

So aborting is very straightforward since the source is basically unaffected
by the "pvmove" except at the very very end.


Stefan

[Sophie Loewenthal]

Thank you very much Stefan for your clear explanation.

Because this affects a root LV I'll run in single user.
Soph