Maybe not the cleanest, but I tried LVM mirror and didn't like it so much.
What I did was put in a new drive and set up mdadm with raid 1 and a missing
drive. Then I pvmoved the LV to the MD device. As soon as it was done I
pvremoved the old disk and added it to the MD raid set. There is a period of
time that you are vulnerable while the raid set syncs. After I did the move
I had to remove one of the disk and it is still running happily. I intend to
put the other disk back in once I move all my MythTV stuff to my ESXi
server. Then it will be as easy as just syncing the disks again.

Sent from my Droid.

On Sep 8, 2010 5:50 PM, "Von Fugal" <[email protected]> wrote:
> So I don't know where to start looking for the answer to this, maybe I'm
> thinking about it all wrong. I've googled LVM copy, pvmove etc. to no
> avail.
>
> What I want to do is add a new disk to a vg and retire an old disk. I've
> been burned before badly though with just using pvmove, where minutes
> after the move is completed the 'new' (not really so new) drive goes bad
> and the old drive is already 'gone' from the lv. This is not really so
> out there what with the extensive IO done on the 'new' drive. If it was
> at all thinking of going bad... it probably will. What I would like to
> do is copy the contents of the old pv to the new pv, but while still
> persisting the data in a sort of mirror on the old pv for a time. When
> things check out, then I want to just vgreduce oldpv and be done with
> it. I realize I could use lvconvert to turn the concerned lv into a
> mirrored lv, but when it comes time to remove the old pv, it becomes
> very klunky to remove the target pv from the mirror, keeping the new
> one, specifying devices ad nauseum. As well, it makes things even more
> klunky if you have more than one lv on the old pv you're trying to get
> rid of 'safely'. It seems like this would be something that lvm could
> handle exceptionally, but I'm at a loss. Any suggestions?
>
> Von Fugal
> --
> Government is a disease that masquerades as its own cure
> -- Robert Lefevre
--------------------
BYU Unix Users Group 
http://uug.byu.edu/ 

The opinions expressed in this message are the responsibility of their
author.  They are not endorsed by BYU, the BYU CS Department or BYU-UUG. 
___________________________________________________________________
List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list

Reply via email to