Grant Taylor wrote: > On 12/06/2018 02:27 AM, Dale wrote: >> From what I've read, I can use pvmove and pvremove to replace that >> drive. Just tell pv to move the data and when done, remove the old >> drive. After that, the new 6TB drive will be used in that PV and the >> 3TB drive can be used for something else. Is it really that easy or >> is there more to it than that? Pardon me but that doesn't sound >> complicated enough to me. > > I've migrated multiple hundreds of TB of data this way. > > In short: > > 1) Partition the new drive(s) as desired. > 2) pvcreate /dev/$newPv > 3) vgextend $vgName /dev/$newPv > 4) pvmove /dev/$oldPv /dev/$newPv > 5) vgreduce $vgName /dev/$oldPv > 6) pvremove /dev/$oldPv > > This does work well, even if the LV(s) are in use / file system(s) are > mounted. > > I have occasionally had issues where the system seems to not respond, > despite the fact that it is doing what it's supposed to. I wonder if > it's related to the memory leak that J. Roeleveld was talking about. > > Note: I /do/ *STRONGLY* recommend that you do partition the new drive > and /not/ pvcreate the entire drive. — Many of the data recovery > tools /expect/ there to be a partition table. Those that don't care > are happy to work with a partition table. I've seen others be in a > very uncomfortable situation when they /didn't/ use a partition table. > Simple easy thing to avoid painting yourself into a corner. > > >
Grant, I'm not ignoring this email. I just keep rereading it. ;-) I'm uncertain still how I'm going to do this. I'm considering encryption which would mean additional changes and mount points. I'm just not 100% sure yet. I'm considering things that may require a new thread. Thanks much for this info. The list of commands helps, largely. Dale :-) :-)
