[Tfug] RAID on LVM (was Re: FreeBSD vs. Linux)
John Gruenenfelder
johng at as.arizona.edu
Thu Nov 29 22:54:26 MST 2007
On Thu, Nov 29, 2007 at 09:41:49PM -0700, Angus Scott-Fleming wrote:
>
>I hear you there. It's not, however, just payware that has this problem.
>
>I'm trying to find out the pitfalls of RAID with LVM for a new server I'm
>setting up, and I can't find anywhere that lists why people might NOT want to
>do this. Also, I can't find anything about setting up RAID _5_ with LVM;
>RAID _1_ with LVM I can find.
>
>Hints, personal experience, links welcomed.
>
>TIA
>
>Angus
Well, I can offer you my experiences using RAID 1 with LVM. I set it up, ohh,
maybe four or five years ago, I think. It was all new to me (RAID and LVM,
that is) so I followed a handy HOWTO I found. It was specific to Debian which
was fine since that's what I'm using.
Now, I was a bit more adventurous then I possibly should have been and my
setup is actually root on lvm on raid 1. This is harder to do, but it does
give you the ability to lose either HD and have a bootable system.
At the time the regular Debian kernels did not do this, so the installation
procedure was to boot the install CD and at at early stage, switch to a
console. From there, load the RAID modules and build the RAID. Then load the
LVM modules and create the logical volumes. After that you can go back to the
regular install process.
The other DIY part is after the install. I needed to create my own initial
ramdisk (initrd). This was also new to me. Fortunately the HOWTO walked me
through most of it. Essentially, you create a little mini-system image with
the necessary lvm tools and libraries to start your LVM. By this point the
kernel's auto-RAID stuff had already detected and enabled the RAID 1 array.
Debugging the initrd was a real pain, mostly because I was new and the order
of execution seemed a bit unusual at the time. And because you need to
reboot, use a good kernel, send over a new initrd (I was building it on a
second machine for convenience), reboot again, then test the new initrd. Then
repeat. And again, and again...
So... pitfalls... I'm still using a custom kernel and I have to make sure to
update the ramdisk on occasion, such as when the machine no longer boots. :)
To be fair, this has only happened once when the LVM tools in the initrd got
very out of date versus the running kernel. Still a pain to debug, though.
Modern Debian kernels may actually support this... I should really check on
that because it would save me some work.
I don't imagine that the procedure here would differ too much for RAID 5.
That is probably sufficiently complex that you would need to write a raidtab
file, but other than that it should be similar.
RAID... I can see taking or leaving that depending on your particular data
recovery and safety needs, or budget needs since you will obviously need to
spend more on drives. As for LVM, though, it's advanced enough that I
honestly wouldn't put together a server or desktop system nowadays without
using it. If you ever need to replace a drive that isn't dead, the tools make
it very easy to move volumes. The only recent system I haven't used it on is
my laptop since there is no room for another drive and no possibility of
moving volumes between drives unless I get some connectors to put it in my
desktop machine.
Other than kernel and initrd issues, I haven't had any problems with this
setup. That said, I did this for safety and haven't actually had to *test*
that safety yet. Despite the many years I have used computers, since I was a
little kid, I have never had a single HD die on me. Even ancient "hardcards"
and MFM drives where you can hear the heads moving about. So it's possible
the recovery process may be no walk in the park.
??? What was that noise?
--
--John Gruenenfelder Research Assistant, UMass Amherst student
Systems Manager, MKS Imaging Technology, LLC.
Try Weasel Reader for PalmOS -- http://gutenpalm.sf.net
"This is the most fun I've had without being drenched in the blood
of my enemies!"
--Sam of Sam & Max
More information about the tfug
mailing list