From: "Gregory K. Ruiz-Ade" <gregory@castandcrew.com>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] RAID 1 on Device Mapper - best practices?
Date: Thu Nov 20 07:20:02 2003 [thread overview]
Message-ID: <200311191103.57697.gregory@castandcrew.com> (raw)
In-Reply-To: <20031021171817.GA28462@mail.parplies.de>
[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 3176 bytes --]
On Tuesday 21 October 2003 10:18 am, wopp@parplies.de wrote:
> > Ahh, but that's the beauty of RAID and LVM, what you end up with is
> > just another block device. Which ever way you do it you'll get the same
> > benefit.
>
> I believe that is not true. How do you resize a RAID device? The only
> option I can think of is to re-create it, which is clearly beside the
> point. With LVM on top of RAID, you can lvextend (or lvreduce), pvmove
> and so on - where's the problem?
At the risk of saying something _way_ past the point that this thread seems
to have died down (hey, I'm only now catching up on email!):
You don't extend the RAID device, you add a new one, and add it as a new
physical volume to your volume group, and _then_ you can extend your
volumes onto the new underlying RAID device.
And _THAT_ is the beauty of LVM.
> +------+ +------+
>
> | hda1 | + | hdb1 | -> md0 \
>
> +------+ +------+ +- VG0
>
> | hda2 | + | hdb2 | -> md1 /
>
> +------+ +------+
Personally, I'd do it this way:
+------+ +------+ +-----+
| hda1 | + | hdc1 | -> | md0 | = /boot
+------+ +------+ +-----+
+------+ +------+ +-----+ +------+
| hda2 | + | hdc2 | -> | md1 | -> | vg00 |
+------+ +------+ +-----+ +------+
vg00 would then contain logical volumes for all the remaining filesystems.
Two points, though. First, if you're going to do mirroring on IDE drives,
regardless of how hooptie your IDE controller is, _always_ put the drives
as masters on _seperate_ channels, otherwise all your writes could take up
to twice as long, since only one device on an IDE channel can be accessed
at a time.
Second, the beauty of LVM is that you can add a new physical volume to the
volume group whenever you feel like it, and then extend your logical
volumes into that new space. So, you buy a Promise 2-channel IDE
controller, and add two 250GB drives to them. Then, you create a new RAID
mirror set with those.
+------+ +------+ +-----+
| hde1 | + | hdg1 | -> | md2 |
+------+ +------+ +-----+
You can then add that to your VG:
+------+ +------+ +-----+
| hda2 | + | hdc2 | -> | md1 | +------+
+------+ +------+ +-----+ \_____| vg00 |
+------+ +------+ +-----+ / | |
| hde1 | + | hdg1 | -> | md2 | +------+
+------+ +------+ +-----+
You don't lose anything in terms of reliability, unless you lose an IDE
controller, in this case.
this way, you're leveraging the capabilities of both the RAID and LVM
subsystems.
In terms of mirror resync times, I personally have not had to deal with
that, either because so far haven't had a hard drive in a software raid
system fail on me yet. Either I'm lucky or careful to buy good hard
drives, but I'm honestly not sure which it is. :)
Doesn't MD allow background resyncs, anyway? Sure, it might suck the living
daylights out of system performance, but at least it should be usable.
Gregory
--
Gregory K. Ruiz-Ade <gregory@castandcrew.com>
Sr. Systems Administrator
Cast & Crew Entertainment Services, Inc.
[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2003-11-20 7:20 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-17 15:10 [linux-lvm] RAID 1 on Device Mapper - best practices? John Stoffel
2003-10-17 15:29 ` Mike Williams
2003-10-17 15:51 ` John Stoffel
2003-10-17 15:56 ` [linux-lvm] " Måns Rullgård
2003-10-17 16:13 ` [linux-lvm] " Mike Williams
2003-10-22 8:02 ` wopp
2003-10-23 17:52 ` [linux-lvm] Drive gone bad, now what? Gert van der Knokke
2003-10-23 18:59 ` John Stoffel
2003-10-24 0:22 ` Rickard Olsson
2003-10-24 15:23 ` Gert van der Knokke
2003-10-27 8:59 ` John Stoffel
2003-10-27 18:28 ` Gert van der Knokke
2003-10-28 2:20 ` Patrick Caulfield
2003-10-28 13:52 ` Gert van der Knokke
2003-10-28 14:14 ` Jayson Garrell
2003-10-28 14:30 ` Gert van der Knokke
2003-10-28 15:36 ` John Stoffel
2003-10-29 8:54 ` Brian J. Murrell
2003-10-30 8:00 ` Petro
2003-11-26 10:15 ` Harri Haataja
2003-10-28 16:06 ` Glen Harris
2003-10-28 14:55 ` Chris Cox
2003-10-28 8:57 ` Mark H. Wood
2003-10-28 8:40 ` Mark H. Wood
2003-10-23 18:53 ` [linux-lvm] RAID 1 on Device Mapper - best practices? John Stoffel
2003-11-20 7:20 ` Gregory K. Ruiz-Ade [this message]
2003-11-20 8:33 ` [linux-lvm] " Måns Rullgård
2003-11-21 13:02 ` Micah Anderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200311191103.57697.gregory@castandcrew.com \
--to=gregory@castandcrew.com \
--cc=linux-lvm@sistina.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.