| 1 |
On 12/06/2018 02:27 AM, Dale wrote: |
| 2 |
> From what I've read, I can use pvmove and pvremove to replace that drive. |
| 3 |
> Just tell pv to move the data and when done, remove the old drive. After |
| 4 |
> that, the new 6TB drive will be used in that PV and the 3TB drive can |
| 5 |
> be used for something else. Is it really that easy or is there more to |
| 6 |
> it than that? Pardon me but that doesn't sound complicated enough to me. |
| 7 |
|
| 8 |
I've migrated multiple hundreds of TB of data this way. |
| 9 |
|
| 10 |
In short: |
| 11 |
|
| 12 |
1) Partition the new drive(s) as desired. |
| 13 |
2) pvcreate /dev/$newPv |
| 14 |
3) vgextend $vgName /dev/$newPv |
| 15 |
4) pvmove /dev/$oldPv /dev/$newPv |
| 16 |
5) vgreduce $vgName /dev/$oldPv |
| 17 |
6) pvremove /dev/$oldPv |
| 18 |
|
| 19 |
This does work well, even if the LV(s) are in use / file system(s) are |
| 20 |
mounted. |
| 21 |
|
| 22 |
I have occasionally had issues where the system seems to not respond, |
| 23 |
despite the fact that it is doing what it's supposed to. I wonder if |
| 24 |
it's related to the memory leak that J. Roeleveld was talking about. |
| 25 |
|
| 26 |
Note: I /do/ *STRONGLY* recommend that you do partition the new drive |
| 27 |
and /not/ pvcreate the entire drive. — Many of the data recovery tools |
| 28 |
/expect/ there to be a partition table. Those that don't care are happy |
| 29 |
to work with a partition table. I've seen others be in a very |
| 30 |
uncomfortable situation when they /didn't/ use a partition table. |
| 31 |
Simple easy thing to avoid painting yourself into a corner. |
| 32 |
|
| 33 |
|
| 34 |
|
| 35 |
-- |
| 36 |
Grant. . . . |
| 37 |
unix || die |
Archives