I haven't had any experience moving pv's around, but it seems to me that it would be much safer and probably just as fast to create a new vg with the new disk and then just copy the data and change a few lines in the fstab.
And as always, have a backup handy if at all possible. No matter how careful we are those darn computers get the best of our data in the end. - Jared On Sep 8, 2010 6:35 PM, "Daniel Fussell" <[email protected]> wrote: > On 09/08/2010 05:49 PM, Von Fugal 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 >> >> >> >> > I haven't done a pvmove on commodity hardware, but the last time I did a > pvmove, the vg got confused about where the extents were and stopped > somewhere in the middle. As the extents are all still there on the > original disk, I did an lvmcfgrestore to the previous config (lvm2 keeps > a few config backups around just in case), ran an xfscheck, and > restarted the pvmove. Worked great. > > To put it in perspective, I only had 2 or 3 of these mid-move failures. > I was moving around 50 or 60 physical volumes at the time. > > It sticks in my mind that there was an option for pvmove to mirror the > entire pv before removing the old drives extent maps, but I might be > thinking about mirroring on lvm releases with a less reliable pvmove. I > read somewhere about one person's pvmove nightmares, after which they > would only mirror the PVs instead of pvmoving things around. I've not > had that problem. I do have backups of my (rather large) volumes, so > venturing in the the land of lvmcfgrestore was much more relaxing (and > successful). > > Where the pvmoves are highly sequential, I wouldn't expect the drive to > fail from excessive head thrashing. Maybe run badblocks on the (empty) > drive before a pvmove? > > Grazie, > ;-Daniel Fussell
-------------------- 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
