Slashdot Mirror
Managing RAID on Linux
A person deciding to go with RAID faces a panoply of options and gotchas. Hardware or software? How many controllers? ATA or SCSI (or ataraid)? RAID 1 or RAID 5? Which file system or distribution? Kernel options? Mdadm or raidtools? /swap or /boot on raid? Hybrid? Left or right symmetric? One poster pointed out that putting two ATA drives on the same controller could impact performance. Yikes! Didn't I do that? Upon discovering that O'Reilly had just published its Managing RAID on Linux book, looking at sample chapter , I bought the book and let my blood pressure return to normal.
RAID is one of these subjects that is really not complex; it's just very hard to find all the information in one place. This is precisely the book to solve the problem. Author Derek Vadala, sysadmin and founder of Azurance.com, an open source/security consulting firm, has gathered a lot of information and even personal anecdotes to go through the decision making process when going over to RAID. He goes step-by-step through that process, educating us about hard drives, controllers, and bottlenecks along the way. This exhaustive book may be the first to bring RAID to the masses.
Although parts of the book (RAID types, file system types) may seem already familiar to experienced Linux users, it is helpful nonetheless to have everything in a nifty little book. A section of file systems provided not only a rundown of the merits and drawbacks of each one, but also a guide to their utilities. I learned for example what "file tails" for Reiser are, and why using them causes performance to degrade after reaching 85% capacity. The book compares raidtools with mdadm as well as lovely commands like nohup mdadm -monitor -mail=paranoidsysadmin@home.com (which, if you haven't guessed, causes the system to email you RAID status reports upon boot).
People who use software RAID may skip over the chapter on RAID utilities for the leading RAID controller cards. Still, there was one interesting tidbit: Why, the author asks, do makers of controller cards put all their BIOS utilities on DOS floppies which require us to find a DOS boot disk? Seriously, how many of us carry around DOS boot disks nowadays? The book made me aware for the first time of freedos, an open source solution that solves precisely that problem.
The Software RAID stuff was pretty thorough and clarified a lot of things. The book does an excellent job in helping to identify and eliminate bottlenecks and optimizing hard drive performance (using hdparm and various monitoring commands). The anecdotes and case studies definitely clarified which RAID solution is suited for which task.
I am less impressed by the book's sections on disaster recovery and troubleshooting. Although these subjects are brought up at several places in the software RAID chapter, the book could have discussed several failure scenarios or used a fault tree (such as the famous Fault Tree in Chapter 9 of the Samba book, a marvel for any tech writer to read). The book doesn't even discuss booting with software RAID until the last 10 page of the book and then gives it only a single paragraph (even though the author acknowledges it as "one of the most frequently asked questions on the linux-raid mailing list."). Call me old-fashioned, but isn't the ability to boot into your RAID system ... kinda important? As someone who just spent a significant amount of time troubleshooting RAID booting problems in Gentoo, I for one would have liked more insight into the grub/lilo thing. Also, in the next paragraph in the last chapter on page 228, the author casually mentions that "all /boot and / partitions must be on a RAID-1." Say what? Please pity the poor newbie who religiously follows the instructions in the book but fails to read until the end. I'm not sure what the author meant by this statement, but it required a much more substantial explanation and needed to go into a much earlier chapter.
These complaints don't detract very much from this excellent book, a true O'Reilly classic and a model of clarity and helpfulness. This book provides enough knowledge to avoid the dread and uncertainty that comes with trying to tackle Linux RAID. With a book like this, a sysadmin can sleep a little easier.
Recommended Readings:- Reliable Linux , by Iaian Campbell, Wiley and Sons, Dec 2001, ISBN: 0471070408. Gives excellent information not only about RAID but on general Linux reliability issues.
- Software RAID in the Linux 2.4 Kernel by Daniel Robbins. (Part Two).
- Linux Journal Article on Software RAID by Joe Edwards, Audin Malmin and Ron Shaker. ( Part Two).
- "How to do a gentoo install on software RAID" by Chris Atwood. Gentoo User Forum.
Robert Nagle (aka Idiotprogrammer )is a Texas technical writer, trainer and Linux aficionado. You can purchase Managing RAID on Linux from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The performance hit is not worth the return.
For you, it's not. For someone else, it might be.
There are any number of situations where it might be appropriate to exchange some performance for increased data security. Just because you can't imagine them, doesn't mean they don't exist.
The learning curve on most Wintel software is on the order of the time needed to search through half a dozen menus to find the right command.
Trying to make everyone be an expert before they can operate their machine is how operating systems die.
Software RAID, excepting mirroring a pair of drives, sucks. Period. The performance hit is not worth the return. Ever do stripping in software? Worse, RAID 5 in software? It sucks. You could spend a few $ and get hardware RAID and not only actually get better performance but not be concerned that some corruption in your OS that is managing that RAID will affect the data stored on it.
It sucks on your hardware. When you use fast SCSI disks and have fast CPU(s), software RAID is much faster then (very expensive) hardware RAID solutions. The chip on your hardware RAID card (usualy ARM) can't be faster than CPU.
Regarding trust, you should trust (open source) software RAID more than proprietary firmware.
While I'm certainly a proponent of "dead-tree" documentation, I have to take a moment to disagree with one of the statements made -- I'm sorry, but newsgroups, while perhaps containing out-of-date info, are (if it's a good newsgroup) capable of letting you know the current state-of-affairs. This is substantially -less- true with books. Case-in-point is Samba: it's *DARN* hard to know, from the Amazon description (or wherever) which Samba books describe the current state (2.4 and above) of Samba, whereas the FAQs, newsgroups, etc., are fairly obvious on it. Bottom line? I'll take a good book any day, but when in doubt, I'll go with current info gleaned off the newsgroups and other on-line resources.
Hmm, I get rather good performance from my IDE software RAID-5. As far as I can tell, reading from the buffers pretty much maxes out the PCI bus and I also get good performance for actual platter reads. Here are some quick numbers:
(granted this is not an exhaustive benchmark)
Not spectacular, but certainly more than fast enough for my media server. Also probably better than I could do on a 68-pin Ultra Wide SCSI bus, even with multiple drives.
Enigma
With disk drives steadily increasing in size, and backup options not keeping pace, everyone has a use for RAID 1. Frankly an extra 100 bucks on another drive is well worth it in comparison to the hassle of maintaining an ongoing backup process. I don't really care that I'm "wasting" a whole drive, since it's still going to be a ton cheaper than any RAID 5 solution.
Ever ripped 500 CDs to MP3 format?
Ever done it twice?
I have, and never will again if I can help it...go RAID 1 go!
When I decided to set up a RAID under Linux, I recalled seeing an icon in my webmin. I used Webmin almost exclusively in setting up the RAID. I didn't need any HOWTOs in the process of setting up this thing.
So while there are good collections of information out there, there are also very good tools out there with which to accomplish useful tasks.
I think it's precisely that HOWTOs are rarely if ever needed with Windows stuff that it still has an edge over Linux where the masses are concerned. So it's nice that HOWTOs are out there, I think it's more important that good tools are out there that are easy and self explanatory.
This post brings up an interesting topic. I too have found may how-to's and online resources available to be outdated. Has anyone setup some sort of Linux HOW-TO/Help Desk WIKI where information can be continually updated by the community? If not, I would be interested in hosting something like this personally. Input appreciated.
-Anonymous Coward
Sorry, but there are some things to be taken into account here.
:)
First of all, some of today's controllers (such as the HSGs or HP Smart Arrays) are running on pretty good RISC chips. Moreover, they have good amounts of memory to use as read ahead or writeback cache, which do speed up I/O instead of sharing memory with the OS.
About the speed of the controller's processor as compared to the main processor, just remember that, in today's standards, one SCSI channel could only work at 160MB/s, and, even if we needed one processor cycle for each byte to be read/written (we don't), we would only need a 160MHz processor to do the job.
Well, come think about it, processors embedded in today's modern RAID controllers usually have a 64-bit data bus. This means that any transaction is 8 bytes long. Being the worst case in performance a RAID-5 write (which involves 4 I/O operations) we still get an average of 2 bytes per processor cycle.
That's why RAID controllers don't come with fantastic processors -- there's simply no need to.
We could also think of availability, but that would be another long issue, and hardware RAID wins almost in all cases (except for controller multiplexing), but the best reason you would have to think about software raid would be the cost.
I could be wrong, though
but the controller's CPU doesn't need to be that fast, most of the logic is in ASICs anyway. the key advantage to having a controller is that it handles all the drive processing and this reduces the amount of work your main CPU has to do. remember: accessing the drive is not all your machine is doing. also most high-end controllers have large memory caches that reduce the load on your system bus, and battery backup that is essential for data integrity during power-loss. for example, in a mirrored RAID situation a software implementation will have to do 2 DMAs per write, one to each drive. with a hardware controller you only need one DMA to the card, the card handles writing to the individual drives, and will often reorganize the order of the writes from its cache.
The "hidden" problem with hardware RAID is that often the operating system isn't aware when an active drive has failed. Some vendors offer monitoring utilities that install into the host OS (eg, MegaRAID controllers have a Linux utility) but this raises dozens of issues. Will the utility impact the server stability or performance? What library dependencies are required for the utility? How do I integrate the utility into my enterprise monitoring system eg, Nagios or Tivoli?
Another problem - perhaps less serious - is that hardware RAID controllers often require a reboot into their proprietary BIOS to do anything. This isn't very useful if you want to expand the RAID array without disrupting service. Some vendors offer utilities to modify the RAID configuration but I've never found all the functionality to be exposed within the utilities. Of course, if you are mucking about with disk arrays on production systems then you have bigger issues to deal with.