bisqwit / lvm2defrag Goto Github PK

I've managed to reduce the bug to a minimal testcase (which I can solve manually), but rearrange.php gets stuck. Increasing the free space helps.

Oddly the first move is trying to move 0 blocks. Increasing the size by an order of magnitude shows that it's actually splitting the first move (and then moving the two halves the same offset, so could have be moved in the same command). but it still gets stuck in the same way:

$ cat dump.txt
!! owner

! /dev/sda2
2       rootA-2
3       rootA-1
(1)     -

$ cat rearrange.txt
!! owner

! /dev/sda2
3       rootA-1
2       rootA-2
(1)     -

$ php -q rearrange.php
# LV split rootA-1 (1 + 2 = 3)
# LV split rootA-1 p2 (1 + 1 = 2)
# Largest temp size 0, desire 1
# Not enough contiguous temporary room for a multipart pvmove
# Not enough room for any of the pvmoves. Splitting a task.
# LV split rootA-1 p2 p1 (0 + 1 = 1)
# Largest temp size 0, desire 1
# Not enough contiguous temporary room for a multipart pvmove
# Moving rootA-1 p2 p1 p1 (0) (Moving away)
echo 'Moving rootA-1 p2 p1 p1 (0) (Moving away)'
pvmove --alloc anywhere /dev/device:3-2 /dev/device:5-4
# Largest temp size 1, desire 1
# Moving rootA-1 p2 p1 p2 (1) (Moving away)
echo 'Moving rootA-1 p2 p1 p2 (1) (Moving away)'
pvmove --alloc anywhere /dev/device:3-3 /dev/device:5-5
# UNABLE TO CONTINUE, NO HOLES FOR rootA-1 p2 p2, FOR rootA-2?
Array
(
    [0] => Location Object
        (
            [pv] => /dev/device
            [offset] => 3
            [size] => 1
        )

)
[... repeats in an infinite loop ...]

$ php -q rearrange.php
# LV split rootA-1 (10 + 20 = 30)
# LV split rootA-1 p2 (10 + 10 = 20)
# Largest temp size 0, desire 10
# Not enough contiguous temporary room for a multipart pvmove
# Not enough room for any of the pvmoves. Splitting a task.
# LV split rootA-1 p2 p1 (5 + 5 = 10)
# Largest temp size 0, desire 10
# Not enough contiguous temporary room for a multipart pvmove
# Moving rootA-1 p2 p1 p1 (5) (Moving away)
echo 'Moving rootA-1 p2 p1 p1 (5) (Moving away)'
pvmove --alloc anywhere /dev/device:30-34 /dev/device:50-54
# Largest temp size 5, desire 5
# Moving rootA-1 p2 p1 p2 (5) (Moving away)
echo 'Moving rootA-1 p2 p1 p2 (5) (Moving away)'
pvmove --alloc anywhere /dev/device:35-39 /dev/device:55-59
# UNABLE TO CONTINUE, NO HOLES FOR rootA-1 p2 p2, FOR rootA-2?
Array
(
    [0] => Location Object
        (
            [pv] => /dev/device
            [offset] => 30
            [size] => 10
        )

)
[... repeats in an infinite loop ...]

PHP Fatal error: Uncaught TypeError: Unsupported operand types: string + int in dump.php:138
Stack trace:
#0 {main}
thrown in /home/s-trace/development/lvm2defrag/dump.php on line 138
An error occurs, fix it and try again.

I recently tried to tidy up my LVM installation and reorder the LVs as needed. Therefore I used this set of scripts. Unfortunately it worked only partly.
To be honest I could have seen this before firing up the ultimate resulting script but it was not that clear in the first moment. I had only a small amount of free space so a whole lot of small movements was generated in order to organize my LVs accordingly. I did not check each and every movement by offset... Never mind, as LVM does not destroy data this way, nothing really bad happend.

I had my /var LV spead thoughout the whole VG into 6 chunks or so. I moved them together in the right order at the beginning just as dictated by the docs. I created the script file (php rearrange.php), checked it for huge errors and gave it a go.
After a few days of hard scrubbing on the PV, the script terminated successfully. I did not think much of it but rechecked a bit later the state. I saw that the original ordering of the chunks was mixed up. As far as I can remember this could have been the original order of the chunks on the VG but shifted together.

Now I tried with a small subset (such that I can explicitly look at the actions performed) but it still took 2 or 3 tries until one LV is ordered correctly.

I assume there is a bug in the business logic to generate the chunks and the corresponding commands. As I have quite some other LVs to rearrange this might serve as a test case. Is there anything I can or should do in order to track this down? Any other suggestions?