[linux-lvm] will pvmove'ing (an LV at a time) defragment?

[Brian J. Murrell]

If I currently have a volume group consisting of two drives and I add a third
drive and them pvmove from the two existing drives to the new drive, will that
defragment my LVs? i.e.:

# pvmove /dev/sda2 /dev/sdb /dev/sdc

where /dev/sdc is the new empty drive.

Or will it just move the PEs from each source disk (in turn) in the order they
appear on the source disk, effectively just concatenating the two sources disks
to the new target disk?

If the answer to the above is yes, if I limit my pvmoves to a single LV at a
time, will that defragment the LVs or will it simply move the "chunks" of the LV
from the first source disk to the target disk followed by the chunks from the
second source disk? (Although likely that will have the desired effect anyway,
as the second disk was added subsequent to the first disk getting fullish.)

Cheers,
b.

[Alasdair G Kergon]

There is no automatic defragmentation available, but you can do it
manually by specifying devices and extent ranges (see pvmove man page).

Alasdair

[Phillip Susi]

Post by Brian J. Murrell
If I currently have a volume group consisting of two drives and I add a third
drive and them pvmove from the two existing drives to the new drive, will that
# pvmove /dev/sda2 /dev/sdb /dev/sdc
where /dev/sdc is the new empty drive.

That will move all extents OFF of sda2 and onto sdb and sdc. I believe
that the default allocation policy will try to locate extents on the
same pv as other extents that lv is using. Whether or not that results
in more or less fragmentation depends on the current layout.

Post by Brian J. Murrell
Or will it just move the PEs from each source disk (in turn) in the order they
appear on the source disk, effectively just concatenating the two sources disks
to the new target disk?

In the above command there is one source disk and two destination disks,
not the other way around. Only the first argument to pvmove is the
source, any additional arguments lists valid destination(s), otherwise
any pv other than the first argument is used.

If you want to defrag your lvs then you need to look at the current
layout with lvdisplay -m and then you can tell pvmove exactly what
extents you want moved to where with something like pvmove /dev/sda:x-y
/dev/sda:q-r --alloc anywhere. The --alloc anywhere is needed if the
source and destination drives are the same, since otherwise pvmove tries
to move the extents to any volume OTHER than the source, and if you
restrict the possible destinations with the second argument to only the
source drive, the allocation will fail.

[Brian J. Murrell]

Post by Brian J. Murrell
If I currently have a volume group consisting of two drives and I add a third
drive and them pvmove from the two existing drives to the new drive, will that
# pvmove /dev/sda2 /dev/sdb /dev/sdc

As was pointed out, this syntax does not even work.

But moving a single LV at a time, first moving the "chunks" off of the first
disk then the second, is resulting in the defragmentation that I was hoping
for. I guess this works reasonably straighforwardly because the second disk
was added as a result of the first disk being full and there has been no mass
freeing of volumes on the first disk to cause future volume expansions to be
done on the first disk after expansions were done to the second disk.

That said, it is quite easy to move portions of an LV, so hooking pvmove into
a disk defragmentation algorithm shouldn't be difficult, if one can find a good
defragmentation algorithm.

TBH, I'm surprised nobody has done such a thing, or if they have, too bad they
did not contribute it back to the LVM project. :-(

Cheers,
b.

[Phillip Susi]

Post by Brian J. Murrell
That said, it is quite easy to move portions of an LV, so hooking pvmove into
a disk defragmentation algorithm shouldn't be difficult, if one can find a good
defragmentation algorithm.

There isn't really any need; having an lv split in 2 or 3 parts isn't
going to cause any slowdown you can notice outside of a synthetic
sequential access benchmark.