From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Q56bv-00064y-7t for garchives@archives.gentoo.org; Thu, 31 Mar 2011 01:23:43 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 83FE01C037; Thu, 31 Mar 2011 01:21:55 +0000 (UTC) Received: from mail-iw0-f181.google.com (mail-iw0-f181.google.com [209.85.214.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 5122F1C037 for ; Thu, 31 Mar 2011 01:21:55 +0000 (UTC) Received: by iwn2 with SMTP id 2so2246285iwn.40 for ; Wed, 30 Mar 2011 18:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=EwxkDnIixbFRNe1tknqs6QBDTMQ689MDMkvQBGLpeAM=; b=iSIp8cNPA589Wck6hB7wQD4E+IjQnzYhW1U3EafcyTxiEmhDSywnxUpHIIHF1KL3Zw 5Enl/7e0K26pkkAPczWB7gDf+D8u7xRTqBsFAviB+t4qlf6RNfJzLaohb4vKlMJzyB7M Bf9RFm1myu305nUbnxxYldXE0MzDe4KmdeSns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=HGqHvesSivm329MlRzyQIBhFoU/jxpQ/WVMZ6MELCSMixDvFCEQY0Heg8Gt3QXkAKU zvXk+4LSZ52lv8Vo8uirDIGiEkDDH6jFpNPAeC9OG0zdgnyqxLggEe2cVZgzGwJXjCb8 DGppidZSRM+8pDSOll01kV/M6J7LFg+ZJ8m80= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.42.171.5 with SMTP id h5mr1940782icz.99.1301534514869; Wed, 30 Mar 2011 18:21:54 -0700 (PDT) Received: by 10.42.77.69 with HTTP; Wed, 30 Mar 2011 18:21:54 -0700 (PDT) In-Reply-To: <20110330073258.BA9B22A12@data.antarean.org> References: <4D92BF88.6000807@binarywings.net> <20110330073258.BA9B22A12@data.antarean.org> Date: Thu, 31 Mar 2011 09:21:54 +0800 Message-ID: Subject: Re: [gentoo-user] How to change from one harddrive to software raid From: Einux To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=90e6ba6e82206bf841049fbd1ecd X-Archives-Salt: X-Archives-Hash: 00f68e66f68d4ee456da9810cbda5341 --90e6ba6e82206bf841049fbd1ecd Content-Type: text/plain; charset=ISO-8859-1 thank you guys, you've been helpful :) On Wed, Mar 30, 2011 at 3:31 PM, Joost Roeleveld wrote: > On Wednesday 30 March 2011 07:28:40 Florian Philipp wrote: > > Am 30.03.2011 05:02, schrieb Einux: > > > Hi, > > > > > > I bought a new 1T harddrive which is exactly the same as my previous > > > harddrive. So I'm planning to make a Raid-1 layout(for security > > > reasons). But here's the problem: I've already setup LVM2 on the > > > existing harddrive and I don't want to destroy the existing LVM volume > > > groups. I tried to google it, but I'm not sure which is the right > > > keyword. Could you guys help me out? > > > > > > Thanks in advance:) > > > > 1. Create a degenerated RAID1 with your new disk > > mdadm --create /dev/md0 --level=1 --raid-devices=2 missing /dev/sdb > > > > 2. Partition the raid device > > > > 3. Add one of the partitions to your LVM volume group. > > pvcreate /dev/sdb2 > > vgextend volume_group /dev/sdb2 > > > > 4. Move everything from the old physical volumes to the new pv. > > pvmove /dev/sda3 /dev/sdb2 > > > > 5. Remove the old and now empty physical volume > > vgreduce volume_group /dev/sda3 > > > > 6. Move everything else which is not on LVM to your new raid. Guess you > > need to go to single user mode to do this safely. > > > > 7. Grow your raid to also contain the old disk. > > mdadm /dev/md0 -a /dev/sda > > > > No, I have not tested this and you should double-check everything. No > > guarantees, etc. > > > > One warning, though: pvmove is known to create problems from time to > > time. Leaking memory, bogging systems with infinite system load and so > > on. If it gives you trouble, you can abort it with `pvmove --abort` and > > try it again later by calling `pvmove volume_group` (without physical > > device specified) to resume it. It SHOULD survive system crashes. > > Trying another kernel version sometimes helps when pvmove gives you > trouble. > > To avoid that, with "large" moves, do the following: > # pvmove -i 600 /dev/sda3 > > The "-i 600" means, only report every 10 minutes. It's the "reporting" that > causes the memory leak. > > Also, when just wanting to "empty" one physical volume, it is not necessary > to > specify the "target". > It's a good idea to mark the PVs on the existing drive "non-allocatable". > Then > LVM won't try to move anything to that PV: > # pvchange -xn /dev/sda3 > > The rest of the steps read correct. It's how I did a similar operation, but > still double-check all the parameters and when in doubt, read the manual > and/or ask on the list. > > -- > Joost Roeleveld > > > -- Best Regards, Einux --90e6ba6e82206bf841049fbd1ecd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable thank you guys, you've been helpful :)
=
On Wed, Mar 30, 2011 at 3:31 PM, Joos= t Roeleveld <joo= st@antarean.org> wrote:
On Wednesday 30 March 201= 1 07:28:40 Florian Philipp wrote:
> Am 30.03.2011 05:02, schrieb Einux:
> > Hi,
> >
> > I bought a new 1T harddrive which is exactly the same as my previ= ous
> > harddrive. So I'm planning to make a Raid-1 layout(for securi= ty
> > reasons). But here's the problem: I've already setup LVM2= on the
> > existing harddrive and I don't want to destroy the existing L= VM volume
> > groups. I tried to google it, but I'm not sure which is the r= ight
> > keyword. Could you guys help me out?
> >
> > Thanks in advance:)
>
> 1. Create a degenerated RAID1 with your new di= sk
> mdadm --create /dev/md0 --level=3D1 --raid-devices=3D2 missing /dev/sd= b
>
> 2. Partition the raid device
>
> 3. Add one of the partitions to your LVM volume group.
> pvcreate /dev/sdb2
> vgextend volume_group /dev/sdb2
>
> 4. Move everything from the old physical volumes to the new pv.
> pvmove /dev/sda3 /dev/sdb2
>
> 5. Remove the old and now empty physical volume
> vgreduce volume_group /dev/sda3
>
> 6. Move everything else which is not on LVM to your new raid. Guess yo= u
> need to go to single user mode to do this safely.
>
> 7. Grow your raid to also contain the old disk.
> mdadm /dev/md0 -a /dev/sda
>
> No, I have not tested this and you should double-check everything. No<= br> > guarantees, etc.
>
> One warning, though: pvmove is known to create problems from time to > time. Leaking memory, bogging systems with infinite system load and so=
> on. If it gives you trouble, you can abort it with `pvmove --abort` an= d
> try it again later by calling `pvmove volume_group` (without physical<= br> > device specified) to resume it. It SHOULD survive system crashes.
> Trying another kernel version sometimes helps when pvmove gives you tr= ouble.

To avoid that, with "large" moves, do the following:
# pvmove -i 600 /dev/sda3

The "-i 600" means, only report every 10 minutes. It's the &q= uot;reporting" that
causes the memory leak.

Also, when just wanting to "empty" one physical volume, it is not= necessary to
specify the "target".
It's a good idea to mark the PVs on the existing drive "non-alloca= table". Then
LVM won't try to move anything to that PV:
# pvchange -xn /dev/sda3

The rest of the steps read correct. It's how I did a similar operation,= but
still double-check all the parameters and when in doubt, read the manual and/or ask on the list.

--
Joost Roeleveld





--
Best Regards,
Einux<= /font>

--90e6ba6e82206bf841049fbd1ecd--