[ale] lvconvert adding mirror speed considerations

[Lightner, Jeffrey]

pvmove had been my first thought but we got a vendor recommendation to do mirroring instead because if something bad happens in the middle of the mirroring (e.g. a reboot) one can resume the mirror but might lose data if it were a pvmove.


-----Original Message-----
From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of Phil Turmel
Sent: Thursday, December 01, 2016 6:01 PM
To: ale at ale.org
Subject: Re: [ale] lvconvert adding mirror speed considerations

You might have better results with pvmove.  Does basically what you've described, but mirrors then removes stripe by stripe.  Not the whole LV.

On 12/01/2016 05:04 PM, Lightner, Jeffrey wrote:
> We’re in the process of migrating from one disk array to another.
> 
>  
> 
> The method we’re using is to zone in the new array to the same 
> fabric(s) in which we have the existing servers and old array then 
> allocate storage from the new array to the servers.
> 
> We then use vgextend to add the new storage device PVs to the existing 
> VG and also add a small device to be used for LVM mirror logging.
> After that we use lvconvert to turn on mirroring for an LV specifying 
> the new PVs (including the log device).
> Once the mirror is complete we do lvconvert to turn off mirroring 
> specifying the old PVs to remove (and the log device).
> 
> This worked fine for a couple of smaller LVs we did yesterday.   We then
> started one to a 6.3 TB LV.   That has now been running for over 24
> hours and appears it will complete around 10 PM tonight. 

_______________________________________________
Ale mailing list
Ale at ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo