[linux-lvm] pvmove is stuck

[Alasdair G Kergon]

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 at redhat.com