On Wed, Aug 31, 2005 at 10:52:01PM +0100, Martin Ebourne wrote:
> pvmove0 vg_hordein 4 p-C-ao 372.56G -1 -1 253 10 /dev/hda1 75.14 247BqL-aEnl-ApBy-bLCf-W2Cs-1spS-GFfERx
> vg_hordein-pvmove0: 0 356515840 linear 22:64 384
> vg_hordein-pvmove0: 356515840 20971520 linear 22:64 356516224
> vg_hordein-pvmove0: 377487360 209715200 mirror core 1 1024 2 3:1 356516224 22:64 377487744
> vg_hordein-pvmove0: 587202560 194117632 linear 3:1 587202944
So pvmove split into 4 parts and it's currently doing the 3rd one. [See man page]
> vg_hordein-pvmove0: 377487360 209715200 mirror 2 3:1 22:64 204799/204800
Look at the last fraction saying how far it got: it suggests you got a
bad sector. Check your system log to see if it reported this (and says
which sector).
The tools don't handle this yet - all they let you do is 'pvmove --abort'
which commits parts 1 and 2 but will abandon part 3.
Several ways to workaround it - none of them trivial.
If you're familiar with gdb, the simplest way would be to use it to
override the status information returned and trick pvmove into
thinking it's reached 204800/204800.
Or compile up a one-off version of pvmove that says in _target_percent()
in lib/mirror/mirrored.c: [this code has moved file recently - lib/activate/]
if (numerator == 204799)
numerator = 204800;
before the existing lines:
if (seg)
seg->extents_copied = seg->area_len * numerator / denominator;
return 1;
There are other options involving editing metadata, but they're harder to
explain.
A way for the system to cope with situations like this automatically is
being worked upon.
Alasdair
--
agk@redhat.com
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
