


Kai Schaetzl wrote:
Bryn M. Reeves wrote on Tue, 09 Dec 2008 10:30:54 +0000:

I notice that I wrote "/dev/sda" where I should have written "/dev/sda3", of course. But I guess this doesn't make a difference.


thank you. I remember this command from reading the LVM how-to some months ago, but had forgotten by now. I had checked the pvchange command, but not this one. After reading man pvmove I'm not sure if using that would really be helpful. If I understand correctly using it will still copy a lot of data (all the data on the LVs). Basically it seems to move out all data from dev/sdan to a temporary lv, then move them back in to /dev/mdn. From

No, that's not correct. The pvmove command works entirely at the level of PVs - no LVs involved and no temporary LVs are created. There is a temporary mirror created between the source PV region and destination PV region and this is then synced. Once the two regions are in sync, the mirror is removed.

This is then repeated for each segment to be moved that is allocated on the source PV. The operation is checkpointed after each segment, so if there is a crash or sudden power failure the operation will automatically re-start from the beginning of segment that was being moved at the time of the failure.

my non-expert view this might create a quite "unfavorable" data layout as it is all happening within the same "data location" on the disk. And all

It will use the same allocation policies as any LVM command. If you don't like the default you can override it via the --alloc option or specify explicit lists of destination PV ranges - see the man page.

in all it might also take longer than a brute-force approach. I had hoped

Maybe, but it's a lot less likely to wreck your data. In practice, I've rarely had performance problems with pvmove.

there's some way to just move lvm metadata so that it knows it belongs to /dev/mdn and not /dev/sdan anymore.

No need. Once the pvmove has completed you can remove the (now unused) source PV using the vgreduce command.

So, I wonder if it isn't as good or even better if I do the following:

- break the raid array md2 (made from /dev/sda3 and /dev/sdb3 with duplicate PVs)
- remove the PV on /dev/sda3
- recreate it and all LVs on /dev/md2
- copy over the data from the LVs on /dev/sdb3

Up to you, I have no experience doing it this way, but this is still going to copy the same volume of data around. I also don't really understand why you want to do all this if the data is already on md2.

