Learn about Linux
Download Linux
Get Linux helpSpecial Offers
Feature: Storage
Benchmarking hardware RAID vs. Linux kernel software RAID
Share
Print
CommentsWant to get an idea of what speed advantage adding an expensive hardware RAID card to your new server is likely to give you? You can benchmark the performance difference between running a RAID using the Linux kernel software RAID and a hardware RAID card. My own tests of the two alternatives yielded some interesting results.
In testing both software and hardware RAID performance I employed six 750GB Samsung SATA drives in three RAID configurations -- 5, 6, and 10. I measured performance using both Bonnie++ and IOzone benchmarks. I ran the benchmarks using various chunk sizes to see if that had an effect on either hardware or software configurations.
For the hardware test I used an $800 Adaptec SAS-31205 PCI Express 12-port hardware RAID card. For software RAID I used the Linux kernel software RAID functionality of a system running 64-bit Fedora 9. The test machine was an AMD X2 running at 2.2GHz equipped with 2GB of RAM. While a file server setup to use software RAID would likely sport a quad core CPU with 8 or 16GB of RAM, the relative differences in performance between hardware and software RAID on this machine should still give a good indication of the performance differences to be expected on other hardware. I tested against about 100GB of space spread over the six disks using equal-sized partitions. I didn't use the entire available space in order to speed up RAID creation.
Because the motherboard in the test machine had only four SATA connectors, I had to compromise in order to test six SATA drives. I tested a single drive on the motherboard SATA controller and then as a single disk exported through the Adaptec card so that I could see the performance difference that the Adaptec card brings to single disk accesses. I then attached the six disks to the Adaptec card and exported them to the Linux kernel as single non-RAIDed volumes. I tested software RAID by creating a RAID over these six single volumes accessed through the Adaptec card. One advantage of using six single disk volumes through the Adaptec card is that it makes the comparison a direct one between using the hardware RAID chip and using the Linux kernel to perform RAID -- the SATA controller that the drives are attached to is the same in both tests. The benchmark between using the motherboard and the Adaptec card SATA controllers to access a single disk gives an indication of how much difference there is in the SATA controller for single disk access. As a minor spoiler, there isn't a huge advantage for either controller for single disk accesses, so the figures of accessing the six disks individually and running software RAID on top should generalize to other SATA controllers. Knowing the performance differences of using the Adaptec card to access a single volume as opposed to the onboard SATA controller you can focus on the difference between hard and soft RAID benchmarks.
I ran tests using both the ext3 and XFS filesystems. These filesystems were created to be chunk and stride aligned to the RAID where possible. I used the mount-time options writeback,nobh and nobarrier for ext3 and XFS respectively. It seems that using write barriers is extremely costly in terms of a time penalty on the Adaptec card, so running it with UPS and battery backup to protect the metadata instead of using write barriers is wise if you plan on using XFS on it. In addition to the alignment options, I used lazy-count=1 to create the XFS filesystem, which allows less write contention on the filesystem superblock.
In order to understand the legends in the graphs, you have to know about the manner in which the filesystems were created. Hardware RAID configurations all have the prefix "hard." hardext3aligndef is ext3 created with -E stride and mounted without any special options. hardext3alignwb is the same as hardext3aligndef but mounted with the data=writeback,nobh options. The XFS filesystem for xfsdefaultnb was created with lazy-count=1 and mounted with nobarrier. hardxfsalign is the same as xfsdefaultnb but is stride- and chunk-aligned to the particular RAID configuration. xfsdlalign is the same as hardxfsalign, but I made an effort to stripe-align the XFS journal as well. On the software RAID side, the ext3 configuration is the same as the ext3alignwb hardware configuration, the plain XFS option the same as hardxfsalign, and the xfslogalign the same as the xfsdlalign hardware configuration.
As you will see from the graphs, the alignment of the XFS filesystem log to stripe boundaries can make a substantial difference to the speed of filesystem metadata operations such as create and delete. The various configurations are also included on the block transfer graphs because these filesystem parameters can affect block transfer rates as well as metadata figures. I didn't discuss the metadata operation benchmarks explicitly throughout the article but have included them in the graphs. One trend that is hard to miss is that hardware RAID makes ext3 random create and delete operations substantially faster.
Single disk performance
Neither the Adaptec nor the onboard SATA controller is a clear winner for block accessing a single disk. The Adaptec card is a clear winner in the file metadata operations, probably due to the 256MB of onboard cache memory on the controller card. It is interesting that block input is actually higher for the onboard SATA controller than the Adaptec. Of course, the Adaptec card is not really designed for accessing a single disk that is not in some sort of hardware RAID configuration, so these figures should not be taken as an indication of poor SATA ports on the card. Because the Adaptec card does not offer a clear advantage when accessing a single disk, using the Adaptec controller to expose the six disks for software RAID should not provide an unfair advantage relative to other software RAID setups.
RAID-5 performance
The main surprise in the first set of tests, on RAID-5 performance, is that block input is substantially better for software RAID; ext3 got 385MB/sec in software against 330MB/sec in hardware. The hardware dominates in block output, getting 322MB/sec aginst the 174MB/sec achieved by software for aligned XFS, making for a 185% speed increase for hardware over software. These differences in block output are not as large when using the ext3 filesystem. Block rewrite is almost identical for ext3 in software and hardware, whereas the rewrite difference becomes 128MB/sec to 109MB/sec for hardware to software respectively when using XFS.
In situations where you want to run RAID-5 and block output speed is as important as your block input speed, using XFS on a hardware RAID is the choice. In cases where rewriting data is a frequent operation, such as running a database server, there can be more than 15% speed gain to using a hardware RAID over software.
RAID-6 performance
The SAS-31205 Adaptec card supports chunk sizes up to 1,024KB in hardware. For the RAID-6 performance tests I used 64KB, 256KB, and 1,024KB chunk sizes for both hardware and software RAID.
Shown below is the graph for RAID-6 using a 256KB chunk size. The advantage that software RAID had in terms of speed have evaporated, leaving all block input fairly even across the board. The graph for the block output and rewrite performance retain the same overall structure but are all slower. The XFS block output performance becomes 255MB/sec for hardware and 153MB/sec for software in RAID-6.
Using RAID-5 leaves you vulnerable to data loss, because you can only sustain a single disk loss. When a single disk goes bad, you replace it with another and the RAID-5 begins to incorporate the new disk into the RAID array. This is a very disk-intensive task can last for perhaps five or six hours, during which time the remaining disks in the RAID are being heavily accessed, raising the chances that any one of them might fail. Because RAID-6 can sustain two disk failures without losing data, you can sustain a second disk failing while you are already replacing a disk that has failed.
The output figures will be lower in RAID-6 than in RAID-5 because two blocks of parity have to be calculated instead of the one block that RAID-5 uses. The block output figures for using XFS on hardware RAID-6 are impressive. Once again, for rewrite intensive applications like database servers there is a noticeable speed gain to running RAID-6 in hardware.
The difference between write performance shows up on the IOzone graph for 256KB chunk RAID using XFS. Note also that the write performance for hardware RAID is better across the board when using larger files that cannot fit into the main memory cache. The fall-away in hardware RAID performance for smaller files is also present in the RAID-10 IOzone write benchmark.
Shown below is the graph for RAID-6 using a 64KB chunk size. Using the smaller chunk size makes block output substantially faster for software RAID but also more than halves the block input performance. From the block transfer figures there doesn't seem to be any compelling reason to run 64KB chunk sizes for RAID-6.
Shown below is the performance of RAID-6 using a 1,024KB chunk size. The performance of the hardware RAID is about 10-15MB/sec better for rewrite from the software RAID's 55-60MB/sec total. Other than that, using a 1,024KB chunk size removes the block output advantage that the RAID card had for the 256KB chunk size RAID-6.
RAID-10 performance
For the RAID-10 performance test I used 256KB and 1,024KB chunk sizes and the default software RAID-10 layout of n2. The n2 layout is equivalent to the standard RAID-10 arrangement, making the benchmark a clearer comparison.
Shown below is the 256KB chunk size graph. For block input the hardware wins with 312MB/sec versus 240MB/sec for software using XFS, and 294MB/sec for hardware versus 232MB/sec for software using ext3. Given that block output was fairly close and that there are no parity calculations required for RAID-10, I would have expected the block rewrite differences between software and hardware to be closer than they are. It is a little surprising that even without the burden of calculating parity information, rewrite is substantially faster for hardware RAID-10 than software. So once again, if you intend to run an application that demands rewrite performance such as a relational database server, consider spending extra for a hardware card.
When using a 1,024KB block size there is little difference in any block transfer speeds between hardware and software RAID. There is an anomoly with the stride-aligned XFS through the hardware RAID-10 causing a loss of about 50MB/sec in block input performance.
Note that although rewrite performance is very close across the board for hardware and software RAID-10 using a 1,024kb chunk size, the fastest 1,024KB rewrite is 99.5MB/sec, whereas the using hardware 256KB chunks and XFS allows 116MB/sec performance. So for database servers, the 256KB chunk size with a hardware RAID is still the fastest solution. If you are mostly interested in running a file server, the differences in block input and output speeds between a software RAID-10 using a 1,024KB chunk size (288 MB/sec in / 219 MB/sec out) and a hardware RAID-10 using a 256KB chunk size (312 MB/sec in / 243 MB/sec out) are not likely to justify the cost of the hardware RAID card. I chose these chunk sizes for the comparison because they represent the best performance for software (1,024) and hardware (256) RAID-10.
Wrap up
For RAID-10 using a smaller block size such as 256KB you get a noticeable difference between hardware and software in rewrite performance. Hardware beats out software substantially in output for parity RAID, with hardware being 66% faster for block output and 20% faster for rewrite performance in a 256KB chunk RAID-6. Therefore if you want performance and the capability to sustain multiple drive failure at the same time you should investigate hardware RAID solutions. Aside from the benchmarks, the hardware RAID card also supports hot-plug replacement, mitigating downtime to swap out dead drives. Based on these test results you might consider buying some cheaper SATA ports and stripe two software RAID-6 arrays instead of buying a hardware RAID card with the same budget.
My tests showed that the choice of filesystem makes a huge impact on performance, with XFS being substantially quicker for output on parity RAIDs, though in some configurations, such as 256KB-chunk RAID-10 block input, XFS can be slower than ext3.
It would be interesting to extend testing to include other filesystems to see which filesystems performed best for mainly read or write performance. The Adaptec hardware is capable of running RAID-50 and -60. It would be interesting to see how software RAID compares at this higher end, perhaps running a RAID-50 on a 16-port card using four RAID-5 arrays as the base.
Ben Martin has been working on filesystems for more than 10 years. He completed his Ph.D. and now offers consulting services focused on libferris, filesystems, and search solutions.
Comments
on Benchmarking hardware RAID vs. Linux kernel software RAIDNote: Comments are owned by the poster. We are not responsible for their content.
Re: Benchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 141.123.223.100] on July 15, 2008 02:46 PM1) You purchased an obscure POS array controller that you and one other person use. In that case, you purchase two, not one, so you have a spare. Still, shame on you for not purchasing from a known vendor. Your fault.
2) You search Google. A quick search for "+compaq +array +controller", for example, found me array controllers dating back to the SmartArray 2/P in the first couple of hits. I believe those were in use about 8-9 years ago. Hardware, no matter how old, can be found. If your controller isn't found in a search, see the next to the last sentence in answer #1. Still your fault.
3) You restore from tape to a new array. You DO back your data up, right? You aren't stupid enough to simply rely solely on RAID to protect your data, are you? Your boss' fault for hiring you, but ultimately...your fault.
Now, you're going to come back with some obscure way your data is special (it's real-time and we can't go back to yesterday's backup to get it all, for example). Any answer you give, however, is just the scramblings of a twit who doesn't know how to do their job. You either protected the data, or you didn't. Complaining that you work in a small shop is no excuse. It's your responsibility to get the money from management to get you what you need to do the job. If you can't, you're still a failure. I've worked in shops with as few as five people, and never lost a byte's worth of data. As an administrator, IT'S YOUR RESPONSIBILITY. Therefore, if the data's lost, IT'S YOUR FAULT. It really doesn't get any simpler than that, and if you can't understand that, please give me the phone number of your boss so I can instruct him to fire you.
And, before I hear crap about how I need to take some Prozac or some bullshit about my being too harsh on this putz: forget it, you're wasting your time. If you can't grasp how people like this make us all look bad, then you're just as bad as he is. He needs to NOT be working in this industry if he thinks along the lines of his comment, it's that simple. We have more than enough stupid people pretending to be IT folks, the more we can scare out, the better.
Re(1): Benchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 24.98.142.198] on July 15, 2008 08:39 PMThe other statements you've made are mostly correct. Personal responsibility is a good trait, however, jumping to conclusions when you don't know much of the background isn't.
Re(2): Benchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 141.123.223.100] on July 15, 2008 09:45 PMI don't need to know much more than you're trying to abdicate responsibility for a poor decision (using an obscure card from a vendor who isn't going to last through the warranty period). There is absolutely no excuse, including insufficient funding, to not doing your job properly. Since part of your job is to secure the right amount of funding, failing to have enough to do it is still your own failure.
Re(3): Benchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 80.135.141.178] on July 16, 2008 06:22 PMRe(1): Benchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 209.50.173.162] on July 15, 2008 09:27 PM1) The main idea was that you have to spend extra money for the spare controller or you are at risk.
2) About a vendor and 8-9 years. That is not reliable anyway.
3) About a backup. If a backup was good enough then people would use RAID0.
You are not a IT professional for sure.
Re(2): Benchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 141.123.223.100] on July 15, 2008 09:43 PMExactly. If you're not going to get a card from a known, reliable vendor, then you need to buy two. If you buy from a known, reliable vendor, they'll be around for the warranty period to ensure you can get a replacement. Regardless, you should get two anyway because you don't want those servers to be down while you wait for a replacement to be shipped.
2) About a vendor and 8-9 years. That is not reliable anyway.
Not with "Bob's RAID Controllers", no. You can find old Compaq, HP or Adaptec controllers easily enough, though. My point, however, was if you were going to suffer the performance hit on the off chance you might not be able to find a controller in three years...well, that's just stupid. You might also be hit by a bus and no one else can find the receipt for the hard drives, so you can't get them replaced, either. You can always find stupid reasons to not follow best practices, but they remain stupid no matter how well you try to justify them.
3) About a backup. If a backup was good enough then people would use RAID0. You are not a IT professional for sure.
You follow that sentence with a denegration of my abilities? Putz. RAID is not, nor has it EVER been about backup. RAID is about fault tolerance. It's about providing continuous access to data despite a hardware failure. It's about providing you a way of recovering from a hardware failure without downtime. It's about making sure the data sticks around long enough for you to back it up. To suggest use of even higher-level RAIDs in place of backups is easily the dumbest thing I've heard in a long time. Go back to flipping burgers.
Re(3): Benchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 209.50.173.162] on July 15, 2008 10:43 PM2) If we can't afford wait for shipment anyway then I see no reason to discuss what might happen in 8-9 years.
3)
a) Your business might not afford to rollback to the backup. Doesn't matter how often you do the backup.
b) In case if backup is acceptable. How often you can do a backup ? I guess it's 1-2 times a day at most. So you can loose what was done for a day or so. RAID allows you to minimize downtime anyway.
Re(1): Benchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 75.163.187.51] on July 16, 2008 09:13 PMRe(1): Benchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 75.163.187.51] on July 16, 2008 09:14 PMRe(1): Benchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 84.19.238.240] on July 18, 2008 01:43 PMRe: Benchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 192.168.0.139] on July 16, 2008 02:11 PMBenchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 192.88.212.43] on July 15, 2008 02:46 PMKeep in mind that RAID is not just for fileservers these days, plenty of hosts are using it for their webserver, or database server. I would like to see real world performance implications when running say, software raid vs. hardware raid on a database server, where the extra CPU usage from the software raid array is no longer negligible.
Regardless of this, thank you for the excellent article on a touchy subject. I know many admins on either side of the fence, and your article seemed fair and unbiased.
Benchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 216.123.194.211] on July 15, 2008 03:40 PMNice.
It would be interesting to do this using :
Some different brand RAID cards.
A server board, without known memory bottlenecks. I assume you used an Intel board and CPU?
Benchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 194.8.30.253] on July 15, 2008 04:07 PMBenchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 213.237.47.228] on July 15, 2008 05:27 PMI think yo could have tested more raid-10 layouts, the n2 layout is standard, but a number of tests have shown that this layout is the slowest, the f2 and o2 layouts are faster. And as you do not know which layout the Adaptec controller is using - they could well use some improved layout - then you could also have used linux SW raid enhanced layouts. After all, this is about getting the most out your hardware. The raid10,f2 and o2 capabilities come for free with the kernel.
You may actualy have gotten more out of your disks if you just had put it on the mobo SATA controller, The first graph indicate that the mobo delivers 90 MB/s while the adaptec card only delivers 70 MB/s.
For 800 USD you could have gotten some cheaper controller and then some more disks, this would most likely have bought you more space and more performance. I think you could have got 2 disks more + a faster SATA controller.
There is a wiki on Linux SW raid on http://linux-raid.osdl.org/
Worth a read, as a complement to those benchmarks :
http://linux.yyz.us/why-software-raid.html
(I particularly agree with his argument regarding how bad could firmwares be nowadays).
its also allowed some strange requests to go through successfully, like converting two raid0 arrays to a raid5 array without downtime (a little LVM magic needed but was at least possible with software raid)
Benchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 192.168.0.10] on July 16, 2008 08:49 AMBenchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 122.167.29.20] on July 16, 2008 09:21 AMOn another subject, would linux.com staff consider adding a "Too abusive -- report for deletion" button next to the "Reply" button on comments? It is no doubt impractical for anyone to actually review and make such decisions, so a count of such button pushes (only if any) next to the comment would be enough. My guess is that a large majority of readers enjoy good articles followed by comments flowing into discussions, but find the enjoyment tends to evaporate on coming across abusive wording. This would help.
Benchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 192.168.0.10] on July 16, 2008 12:06 PMThe position of the start of a partition used for a RAID array can affect the performance of the array. See this thread for details:
http://www.mail-archive.com/linux-raid@vger.kernel.org/msg10093.html
It can help if the partition start lies on a 64k boundary. Some graphs illustrating the performance impact can be found here:
http://sqlblog.com/blogs/linchi_shea/archive/2007/02/01/performance-impact-of-disk-misalignment.aspx
I'd be interested to see some of the above benchmarks run again with partition start positions at 63.5k, 64k and 64.5k to see the impact on performance.
One other thing, when posting benchmarks such as the ones above it is useful (in the spirit of the scientific method) to state the hardware used, BIOS version(s), operating system version(s), driver version(s) and the exact steps/commands used to create the RAID arrays and filing systems so others can recreate the tests. I for one would be very interested in the commands you used to create the XFS filing system as I'm interested in tuning XFS performance on my own systems.
Benchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 68.108.246.84] on July 16, 2008 07:58 PMBenchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 122.167.29.20] on July 17, 2008 02:42 AMBenchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 78.105.172.180] on July 17, 2008 10:17 AMThe format of your work above is great, I had no problem reading the charts. The addition of the hardware/software config and build data would make it better still.
Benchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 64.56.206.254] on July 17, 2008 09:34 PMOne of the posters has it completely right -- spare controllers, standby machines, and backups. Any IT job seeker here who mentions software RAID will be smacked upside the head and shown the door.
Re: Benchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 62.2.234.130] on July 25, 2008 02:57 PM>Hardware controllers with battery-backed cache is the only way to go.
Interesting. Do you know what you are talking about? You don't! I have been using Linux Software RAID on Debian for 4 years now, non-stop, on around 6 servers. I have not had one problem yet, NONE! It is robust enough. Linux has not just graduated from being a toy. You are behind with your information, about 4 years, because that is when it gratudated into being enterprise grade. Software RAID has since then evolved into more and more rock solid stability and I would bet all my information on it, as I do currently. (And I am extremely paranoid of losing it.)
>One of the posters has it completely right -- spare controllers, standby machines, and backups. Any IT job seeker here
If I would hear you utter things like this, I would kick you out on grounds that you are totally non-innovative, lack creative problem solving skills, i.e. looking for cheaper and better ways to run things. You are a menace to the profit margin of a company. Or to put it differently: You offer what everybody else working in the field does, nothing special, replaceable.
Backup is no discussion, you need it, no matter what RAID you run.
My theory is that most hardware raids will be replaced with software RAIDs in the future, because HW raids are too expensive for what they do. (spending 1600$ for 2 RAID cards will offer you to buy tons more diskspace in Software RAID, another controller card and TONS of spares)
And lets face it, 800 bucks is a cheap RAID card.
Benchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 89.8.130.96] on July 18, 2008 12:03 AMBenchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 70.119.135.226] on July 18, 2008 02:11 PMA software RAID will stomp hardware RAID in most test cases where the machine is only running the RAID test.
The only way a hardware RAID out performs software RAID is a real world test.
Get the CPU to 100% utilization running application software while running the RAID test, and then see how your software RAID compares to a hardware RAID.
Benchmarking hardware RAID vs. Linux kernel software RAID - RAID10?
Posted by: Anonymous [ip: 68.236.140.141] on July 18, 2008 07:16 PMU: RAID alignment in presence of partition table
Posted by: Michael Shigorin on July 19, 2008 08:09 AMBTW folks around also tell that moving XFS journals to a separate spindle (or mirror, if there's less loaded one) helps a lot.
2 anonymii: would you please refer to the "stupid comments" by ip/date/number_from_top? It's a bit amusing (shows that we have a lot of stupid pride in ourselves in IT industry -- worldwide indeed, local comments on opennet.ru were quite similar) to decipher but a bit annoying as well.
I can only add that if someone's trying to make anyone *miss* any risks out there, *he's* at fault. It's extremely stupid and unprofessional to rely on vendor's goodwill or stability these days, and extremely rude to skip "after warranty period" sentence in initial comment while replying with "during warranty". When there can be a problem, one should better know how it can be, not stick the head in the sand.
And yes, RAID and backup aren't mutual substitution. I've recently added 2x500Gb disks to my home box (partially mirrored, / and /home) while phasing two older drives out (they were older than 3 years already, hence not considered reliable) and kept 320Gb one as a backup. That's just a humble quiet home box running on 1kVA UPS. :)
Benchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 64.46.1.14] on August 14, 2008 05:15 AMAnd with that in mind, if it's there why not use it. At work we have well over a thousand servers and I can count on one hand the number of times controller failure has been an issue in the last 5 years (and still have a few fingers left over). Since in every case the server was under warranty (you're an idiot if you run them out of warranty without spares) the vendor was on-site within a few hours with a replacement component. If you're concerned about those <4 hrs we experienced after each controller failure (e.g., let's say they were critical systems) - then use multiple controllers on those systems, or implement some form of fail-over clustering.
This is basic stuff guys... I can see the SW vs HW RAID controller argument as being valid for your home computer, but really I don't see it having a place in the enterprise.
Benchmarking hardware RAID vs. Linux kernel software RAID
Posted by: Anonymous [ip: 24.98.142.198] on July 15, 2008 02:11 PMI think we can all agree that RAID is the best answer (not RAID-0) regardless.
Software RAID doesn't have the dead controller issue. Simply plug the array into another Linux box, import the array metadata and start the array up. The disk controller hardware doesn't matter. Backing up the array metadata becomes critical, but that is tiny - much smaller than your Quicken financial files.
Don't get me wrong, sometimes you *must* have the performance that hardware RAID provides - usually by that point you need a fibre attached array and a SAN anyway with 64+GB of cache like a cheap EMC or HDS provides. Or a highly redundant NAS with redundant RAID controller cards. Yes, cheap is a relative term here.
Bringing a high cost solution for all the storage needs is wasteful. The right tool for the right performance/protection is what is required.
#