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 1Q6XWj-0004io-E9 for garchives@archives.gentoo.org; Mon, 04 Apr 2011 00:20:17 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 630C71C02C; Mon, 4 Apr 2011 00:18:28 +0000 (UTC) Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com [74.125.82.181]) by pigeon.gentoo.org (Postfix) with ESMTP id E8FAB1C02C for ; Mon, 4 Apr 2011 00:18:22 +0000 (UTC) Received: by wyi11 with SMTP id 11so5687805wyi.40 for ; Sun, 03 Apr 2011 17:18:22 -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:from:date :message-id:subject:to:content-type; bh=GAiKcB16WV4ypKWO/T/MzXglo2hwZKQZCdGGSSZdx1w=; b=KOEAieyF5+YTyqBv+Khb6g/RQ8L1eBj2nOaIjAyIKRzK5qydsbwafxGqk6n0Pt5i/h u1xuHxoJ+btEhBsaUvB4Y+iCHAWG8fno1iYR62Mzgsgk3XqC/YE43vUYaV2YlH8EoiJX X9v/AkX69lHfTwVu/TdqhHN12VeQslwvYcXJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=dONPS8N16ZgNHvsfeV+KvsIFcRSpBQVhrtXUizjT0ZbBHZLDGo2XsYiRGfX4r5dL5C DyIe2zQIagMeXqzDZlSsaZp2DaI72r73IVlXQnCGG2lMv1JYN52Fx3KSuT9aM1WsEMWY jxYGvLuOgOkDft6B5y7qxXQUu5/EZfIMHf2zA= Received: by 10.227.153.145 with SMTP id k17mr4840090wbw.18.1301876302059; Sun, 03 Apr 2011 17:18:22 -0700 (PDT) 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.227.21.141 with HTTP; Sun, 3 Apr 2011 17:18:02 -0700 (PDT) In-Reply-To: References: <4D92BF88.6000807@binarywings.net> <20110330073258.BA9B22A12@data.antarean.org> From: Mark Shields Date: Sun, 3 Apr 2011 19:18:02 -0500 Message-ID: Subject: Re: [gentoo-user] How to change from one harddrive to software raid To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=0016e6dd8f3d869eb704a00cb216 X-Archives-Salt: X-Archives-Hash: 88b31c908541af3d41a89be7b7ec971c --0016e6dd8f3d869eb704a00cb216 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 30, 2011 at 8:21 PM, Einux wrote: > 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 > > I starred this in Gmail in case I ever need to do something like this. Thanks guys! --0016e6dd8f3d869eb704a00cb216 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 30, 2011 at 8:21 PM, Einux <einuxnet@gmail.com&g= t; wrote:
thank you guys, you've been helpful :)
=

On = Wed, Mar 30, 2011 at 3:31 PM, Joost Roeleveld <joost@antarean.org>= wrote:
On Wednesday 30 March 2011 07:28:40 Flo= rian 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 disk
> 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

I starred this in Gmail in case I ever need to do= something like this. =A0Thanks guys!

--0016e6dd8f3d869eb704a00cb216--