[linux-lvm] RAID 1 on Device Mapper - best practices?

[Gregory K. Ruiz-Ade]

On Tuesday 21 October 2003 10:18 am, wopp at 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 at castandcrew.com>
Sr. Systems Administrator
Cast & Crew Entertainment Services, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20031120/b1766426/attachment.sig>