Hendrik Boom wrote:
> Bob Proulx wrote:
> > I am not quite in sync but wanted to post that pvmove will move data
> > from one PV to another PV. I have used it often.
...
> Can it move file systems from one volume group to another volume group?
> Because that's the situation I have here.

No. Sorry. That would be within a volume group. If the data needs
to move from one VG to another then it needs to be copied via the file
system such as using rsync.

> And while I'm at it, I may as well merge / and usr to avoid trouble
> with the sadly expected usrmerge. And I may have to update the
> entries in /etc/fstab accordingly.

The dreaded UsrMerge. It's mostly a one way trip.

> Looks like all I'll have to do is move a few file systems from VG1 to VG-3T.
> The example on the pvmove an page is:

Sorry. Can't move from one VG to another VG. AFAIK anyway. I think
you will have to copy the data at the file system level. (If I am
wrong about this I would love to learn the details of the feature.)

>     Move extents belonging to a single LV.
>     pvmove -n lvol1 /dev/sdb1 /dev/sdc1

The particular specific to move extents associated with a single LV is
because, I think, that a VG that is missing a PV can still serve the
content of the LV *IF* and only if all of the extents are contained
within the existing PV.

Which creates this situation where if at boot time all of the root
file system is available on a PV but another PV is not available. It
will still be able to serve root. And therefore boot. And then
subsequently might be able to add in the missing PVs to provide the
rest of the VG.

I hit that case myself by accident once and learned of this
"interesting" but I found quite confusing behavior. A system had two
disks. Two more disks were added. But at boot time it only knew
about the original two disks and not the new ones. *Six months go by
okay* and then one day it would not boot. The root file system had
finally grown to the point that LVM placed some extents on the new
disks, which were not available at boot time due to a configuration
error. That took me a while to figure out. Now that I have been once
burned by it I am aware of it and have avoided that situation since.

> Unfortunately, the document doesn't manage to say which argument is the
> source and which is the destination. I'm guessing that the /dev/sdb1 in
> the example is the source, and that /dev/sdb1 is the destination, but I
> haven't actually seen that stated.

I don't find that particular feature useful. I want to vacate an
entire device of all extents and not just from one LV. Therefore I
have not used it. But I believe the first argument is the source and
the last argument is the destination and with the -n option limits the
blocks moved to only that LV. But I recommend not bothering with the
option -n lvname and move all or none. And I usually let LVM decide
where to put the data on the remaining storage.

Good Luck!
Bob