IDE RAID Examined
Bender writes "The Tech Report has an interesting article comparing IDE RAID controllers from four of the top manufacturers. The article serves as more than just a straight product comparison, because the author has included tests for different RAID levels and different numbers of drives, plus a comprehensive series of benchmarks intended to isolate the performance quirks of each RAID controller card at each RAID level. The results raise questions about whether IDE RAID can really take the place of a more expensive SCSI storage subsystem in workstation or small-scale server environments. Worthwhile reading for the curious sysadmin." I personally would love to hear any ide-raid stories that slashdotters might have.
IDE can only handle one or two hard drives per channel, which makes the cabling a real nasty hassle as opposed to SCSI-based RAID.
Even those so-called rounded cables can clutter the hell out of a tower case if you have a 4-channel RAID controller.
In my case it's the Adaptec 2400A four-channel, with four 120GB Western Digital hard drives, RAID 1+0.
Whats the point in having SCSI-Raid in most workstations these days? I mean, ram is so cheap now you can throw in a couple gigs for much less then the price diffrence between SCSI RAID and IDE raid.
I mean, I know the hest drives are SCSI flavor, but it seems like there's so many other things you could spend money on first that would get you way better performance, like getting a Dual Athlon CPU or something.
autopr0n is like, down and stuff.
At the company I work for, IDE RAID has become somewhat standard because we're basically cheap... At least it's standard on the servers that are fast enough to support it. The rest use dd to copy partitions between backup drives. My boss calls it "RAID point five" We lovingly refer to it as the ghetto network.
I ran an IDE RAID, one of the first, a few years ago. It was a 3ware RAID-1 controller. I thought it would be useful because I had gotten sick of losing data on a drive failure. I didn't have the money (or patience :) for a good backup solution and Linux RAID hadn't matured.
... never have I seen 2 drives go down simultaneously. Nor have I seen a controller malfunction in a way that damaged the drives (though I've heard of it from other people).
Everything was fine for awhile. After a few months I lost a drive, replaced a drive and it remirrored fine. Same thing happened a year or so later.
Then one day my controller fried. Nothing else in the system went down, but some kind of surge hit the 2 drives from the RAID controller. The controller still worked but neither drive was accessible, either as RAID drives or as single drives. Tried numerous tricks, eventually gave up.
I've run SCSI RAID in boxes I admin at work
All in all, I decided it wasn't worth it. I am currently doing Linux mirroring in combination with journaling filesystems on one box, and Windows mirroring on another.
It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
---- El diablo esta en mis pantalones! Mire, mire!
I personally would love to hear any ide-raid stories that slashdotters might have.
Once upon a time, in an array far, far away, there lived a young princess who was worried about the integrity of her data...
My favourite quote from the article : As an added bonus, the lights sometimes flash in a side-to-side in a pattern reminiscent of Knight Rider's KITT.
You would think that after 130 graphs comparing the controllers he could come up with a stronger conclusion than "I cant really decide which one is the best"
"The defense of freedom requires the advance of freedom" - George W Bush
A friend of mine set up a raid0 (striped array) using the built-in raid-controller in his motherboard. Later, this motherboard had to be changed. To our great surprise, the raid information was only stored in the motherboard and thus permanently lost. This could be a good thing to know ... Make sure the data is not lost if the controller fails.
Personnally, I run several software RAID arrays under Linux and it works very well. It's easy to manage and gives me decent performance on my rather old machine.
I feel very confident in mirroring system/boot partitions on my linux machines =)
My experiences with IDE RAID have been pretty darn good. Benchmarking my Desktar 60GXP drives in Windows 2000 last year showed that I was getting read speeds in striping mode (between two drives) at faster rates than the fastest seagate Cheetah SCSI drives. Times have probably changed now though.
I started with a KT7A-RAID mobo. The important thing is that you get the cluster sizes just right for your particular partition. I used Norton Ghost to image my drive and try all sorts of different variables. In the end I had very satisfying results. Since I switched to Linux, I stopped using RAID-0 (yes, it is supported with this device!). I found that ReiserFS and the multi-drive Linux filesystem on these drives seemed to be just about as fast without having to hassle with soft-RAID controllers. It is probably due to my system RAM though. I couldn't seem to get Windows 2000 to make the most of 1024 MB without using that swapfile. Linux seems to avoid the swap altogether and uses static RAM instead. It is very nice having the extra IDE channels though. Without them, I probably wouldn't have 4 HDs hooked up right now.
True, but both cheep IDE drives and expensive SCSI drives are cheep compared to something like a 7133 Serial Disk System today. And especially cheep compared to "enterprize" storage solutions of yesteryear when RAID was coined.
I bought that about a while ago when the maxtor 160GB 5400RPM drives started to ship.
:) Reminds me when I plugued my first gigabyte drive in my amiga and saw big numbers :)
:).
I had to build a datacenter and storage price was the main issue. I had to have something cheap, yet hold a LOAD of data. Problem is personally I hate maxtor drives, I always found the more or less reliable (but drive experiences varies from a person to another so..). Anyways at that time maxtor were the only one offering 160GB drives, at a decent price/meg, and although 5400RPM is quite slow for access time, the main issue was cost so I could take a hit on access speed as long as "streaming" speed was fast enough.
the Adaptec 2400A card was the best at the time, simple, cheap efficient, it had 3 bad sides for my application, no 48Bits LBA support (130GB+), no 64bits PCI version (I was using a K7 thunder, and that chipset will slow down the pci bus to the slowest card connected to to bus, and since I wanted all available bandwidth to be thrown to the 64bits gigabit card, I couldn't accept using 32bits), and finally, no more than 4 drives. I wanted to break the terrabyte limit, so let's say I would have used 2 of those cards, it wouldn't have been price-performance-wise since the 2 would have shared the bus and I would have lost 2 drives for raid-5 instead of one with a 8 drive setup. but the performance of the Adaptec 2400A was the best. Still looks like the best overall today, yet I dunno if they are supporting 48bits LBA?
Anyways the 3ware 7850 was an excellent choice. Although their tech support is more or less good (like most tech supports) especially for real bugs and not just standard drivers reinstallation issues, the response time and sales people were very nice and professionnal. I got surprising results from the array, where I thought it would run like molasse, I was getting over 50MB/sec sustained non-sequential reading if I recall correctly. And the tools are very good, rebuild time is about 3-4 hours with 8x160GB @ 400GB filled on the drives, there are email alert tools and web interface to the host machine to check diagnostics. Overall it's a nice system and I'm sure the 7500 series are even better.
Oh and on a "funny" note, windows shows 1.1TB available in the explorer window, not 1134GB
As for the maxtor drives, I didn't take any chances, I ordered 10 to get 2 spares, 2 blew off in less than a month, but didn't have any problems since then, I guess if you can afford the time, doing a 1 month burn-in test with non critical data isn't overkill. usually they SHOULD blow up one by one so you could rebuild the array
--- Metamoderating abusive downgraders since my 300th post.
Thats bullshit. Post some links to benches that back that up.
Two 80GB WD special edition drives in RAID 0 (7200RPM, 8mb cache) rarely burst over 90MB/s. They usually have a sustained transfer of ~50-65MB/s.
Additionally, your seek time is going to suck. I gaurantee its not going to be under 11ms. You cpu utilization during transfer will prolly be around 4% in the asolute best case senario and 11% on average. This is becuase, no matter what you think, all raid cards under ~140$ do the calculations for the transfers in software, not hardware. All you have is a controller card with special drivers. You wont come even close to beating the overall performance of a scsi 160 drive, or SCSI 160 RAID 0 setup.
HP has developped a pretty cool type of RAID. An automatic RAID-level that automatically organizes your disks for best performance while maintaining security.
When a friend explained it to me, it sounded like a mixture of raid 5 and 0+1. For example, if you replace a disk with a larger one, the extra capacity will be used to duplicate some other part of the array.
White papers here
We've run several big RAID-5 setups on 3ware cards. When I say big I mean 1TB+ on each card. To do this we've used the 100GB+ drives available (120GB - 160GB) The biggest problem has been drive failures. Out of the 40 drives I think we've lost 6 in less than 1 year. In only 1 case have 2 drives gone bad at once (RAID-5, we're covered if 1 drive fails), but lost around 1TB of data. Luckily the data could be reproduced but took two weeks to regenerate.
It's WAY too easy to build massive arrays using these devices. How the hell are you supposed to back them up? You almost have to have 2, one live array and 1 hot spare array. If you think you're going to put 1TB on tape, forget about it. If you have the cash to buy tape technology with that capacity and the speed to be worthwhile, you should be buying SCSI disks and a SCSI RAID controller.
Using IDE Raid is like using a winmodem. Unlike with modems, where everyone has one, RAID has a basic educational entry point. I seriously doubt IDE Raid will ever overtake SCSI in any area where knowledgeable people are doing the administration.
I don't quite understand where this Inexpensive crap came from. RAID was around long before IDE RAID controllers started showing up and of course SCSI RAID arrays almost always use very expesive disks. It's Redunant Array of Independent Disks, always has always will be.
It probably comes from the original reseach paper... A case for redundant arrays of inexpensive disks in the Proceedings of SIGMOD International Conference on Data Management, 1988. (Pages 109-116.) SCSI drives were an inexpensive option compared to other storage technologies that offered high performance and fail over safety.
Over time the acronym expansion was changed to become "redundant array of independent disks" as RAID become more popular (and affordable) for smaller systems.
Some references: here, here and here
have you had any drives go south yet? my experience with promise 33/66 cards a generation or two was that 2 drives on a cable, one bad drive = both drives data gets corrupted. So two cards, 4 drives, 1a,1b,2a,2b, in raid 10 meant one drives dies, all is lost = so much for raid.
ostiguy
Holy cow. Sistina LVM (Logical Volume Manager) rocks. It is a partition system/file system of the future that really makes RAID sort of unnecessary. It is true that it is done by the host OS, but when integrated right it does not matter.
Documentation for LVM is great. It is stable and works without quirks. It does all of the things that I would typically desire from a RAID 0,1,5 setup. Administration tools are awesome and give output just as I hoped. Expand partition sizes LIVE (ext2resize needs to unmount though, that is not LVM's problem), move a file system to another physical drive, mirror partitions, spread partitions over various devices. LVM is NUTSO!
It is built into the Linux kernel past 2.4.7 (or somewhere around there), though I have heard that it was inspired from LVM for HPUX. I can't say much about this.
Understanding the concept of how LVM works can be a little hard at first, but once you get past that and then actually use it on a system, you will be totally blown away by what it does and the performance.
Here is the website for LVM
http://www.sistina.com/products_lvm.htm
I personally use Sistina LVM on a Debian Gnu/Linux system that has two IDE 60GB hard disks. I can change the sizes of partitions, move data around, move to a new hard drive on the fly, and tons of things that I don't even think I could do with the highest end of RAID controllers. As for performance, it is software RAID, but it does not have any of the typical software RAID slowness or cruft factor. I initially chose LVM as a cheap alternative to buying an IDE RAID card. Now, I don't even want an IDE RAID controller.
...so be alert.
Each IDE controller can support up to two drives, a master and a slave. What happens if you hang two drives off one controller, and the "master" drive dies?
If it dies badly enough, the "slave" drive can go offline. Now you've got TWO drives in your array that aren't talking. There goes your redundancy.
If your purpose in using RAID is to have a system that can continue operating after a single drive failure, then you better think again before you hang two drives off any one controller.
As it points out in the Linux software RAID docs, you should only have one drive per IDE controller if you're really concerned about uptime. That would imply that "4 channel" RAID cards should only be used with a maximum of two drives, both set to "master", and no "slaves".
Note that this does not apply to SATA drives, as there isn't really a master-slave relationship with SATA -- all drives have separate cables and controller circuits. SATA drives are enumerated the same way as older drives for backwards compatibility with drivers and other software, but they are otherwise independent. (At least that's what I hear, I haven't actually seen one of these beasts yet...)
And of course none of this touches on controller failures, which is another issue. But if you are worried about losing drives and still staying up, then better take this into consideration when you design your dream storage system.
(I don't know about you guys, but I have lost several drives over the years, and not one controller...)
I'm not the original poster but here goes. This is with a three 27gig drive Linux software RAID5 (md). This box has been up and running for about 2 years as my personal file server. All three drives are identical (Seagates, I'm too lazy to lookup model numbers)
/root> hdparm -t /dev/hda /dev/hda:
/root> hdparm -t /dev/md0 /dev/md0:
[10:40pm]
Timing buffered disk reads: 64 MB in 2.70 seconds = 23.70 MB/sec
[10:41pm]
Timing buffered disk reads: 64 MB in 1.40 seconds = 45.71 MB/sec
These are read tests of course but this is a mostly-read file server so that's what matters to me.
Also, it is a highly patched RedHat 6.2 install with 2.4.17 kernel, dual p2-400mhz, 1/2 gig of ram.
I'm using IDE raid on my home desktop right now, but I'm using software raid as opposed to a hardware controller. I have two Seagate Barracuda ATA IV 40GB hard drives hooked up as masters to my primary and secondary motherboard IDE ports. I also have a DVD-ROM hooked up as secondary slave, and a Promise Ultra133TX2 controller with a CD-RW hooked up to its first port. Both hard drives are sectioned into a 3GB primary 1st partition and a 34GB (yes, the drives are only 40GB when you're in marketing land) 2nd primary partition. Windows 2000 is installed on the first drive's 3GB partition, and redhat linux 7.3 is installed on the second drive in the same place. Both OSs share the combined 68GB RAID 0 set, which is formatted with NTFS, made from the combined second partitions. The only problem is that linux can't write to the array because NTFS write support under linux is currently "DANGEROUS" according to the driver's author and I keep important data on there. (Yes, I know about the dangers of using RAID0 and I back up regularly.) It'd sure work a whole lot better if that driver were finished, though. (hint hint, Legato Systems, Inc.) ;)
:D After a quick format with NTFS (the partiton was too big to format with FAT32), I was in business.
/dev/md0
/dev/hda2 /dev/hdc2
/etc/raidtab, ran raid0run /dev/md0, and added a line to /etc/fstab. (I read online that WinNT 4.0's software raid driver uses 64K chunks.)
;) As a bonus, I also get to keep my standard partition table as well as compatibility with non-M$ disk editing/management/recovery tools.
Getting the two OSs' software raid drivers to play nicely together was an "adventure", mostly due to Win2K's insistance on turning the disks into "dynamic disks" before letting me use its built-in RAID functionality, meaning it wanted to wipe out my old partition table, replace it with a single partition taking up the entire disk, and create a new system of partition organization inside the dummy standard partition. After a lot of reading, I found out that Windows NT 4.0 supported "stripe sets" using standard partitions, and that Windows 2000, when installed over an old copy of NT4, would support the "legacy" software RAID drive. Windows 2000 would not, however, allow me to create new legacy stripe sets for compatibility with other OSs. Stupid Micro$oft. So all I had to do was fake Win2K into thinking it had been installed over an old copy of NT4 which had been using its stripe set functionality.
The first thing I had to do was create partitions. I opened up linux fdisk and allocated 3GB on each disk to my OSs, one for linux and one for windows, and created two partitions, each one taking up the rest of the space on its disk, and set their types to 87h (NT stripe set [thanks to whoever put the L command in linux fdisk!]). After installing Windows 2000 on the first disk's first partition, I needed to get my hands on a couple of tools that didn't come with windows 2000: Windows NT 4 Disk Administrator and MS's fault tolerant disk set disaster recovery tool, FTEDIT. After spending about 6 hours searching online, I finally found a download site for FTEDIT - MS's web site says you can get it free from them, but it provides no download link. NTDA was a bit easier. Since MS service packs replace OS files, and somewhere in NT4's history a bug or problem had been found in NTDA, that file was in the service pack 6a for NT4. Service packs check to see if you're using the correct OS _after_ they decompress themselves, and they're nice enough to display an error message telling you this ("Whoops. You just wasted a whole bunch of time downloading a huge file you didn't need. Sorry!") before they delete the decompression directory. Figuring that out took a while, but snagging the executable during decompression was easy.
I ran NTDA, which populated the "missing" DISKS key in the windows registry (Win2K stores disk information in a different place from NT4), and told FTEDIT that, yes, I really did already have a software RAID 0 set on those drives, and that windows NT had died on me and I had to restore it. After a reboot, "Drive D" appeared in my computer. 68GB and unformatted. YAY!
Getting linux to see the array was much easier. I added
raiddev
raid-level 0
nr-raid-disks 2
persistent-superblock 0
chunk-size 64
device
raid-disk 0
device
raid-disk 1
to
Btw, yes, I know linux has support for MS's dynamic disk scheme. I enjoy tweaking and doing new things, even if it means days spend reading about Windows.
"So," you're probably wondering, "why did Erpo spend all that time setting up a RAID0 set (presumably for extra performance) and then go and do a stupid thing like put a DVD-ROM drive on the same ata cable as one of the disks when he has an extra ata port on his add-in controller that he's not using?" Thanks for asking. It's because Promise's bios on the Ultra133TX2 card was broken. The company "Promised" me it would allow me to boot from CD, but in reality it only will let me do so when I want to boot from a windows installation CD. Not just any windows installation CD, either. It had to be Windows 2000 Professional or XP, which I refuse to use.
It wouldn't recognize my Windows 98 SE cd, or any of my linux distros. I didn't have a choice about the DVD drive if I wanted to install linux. Just now, months after I got the card and sent promise and email, they released a bios update that claims to fix the issue. If it works I'll be moving my optical drives around. Even with the DVD drive, the performance isn't too bad - about 80MB/sec at the beginning of the disk, and it slowly drops to 50MB/sec at the end.
Here are the hdparm results of the two machines I currently have that run Linux Software Raid.
/dev/md1 && hdparm -t /dev/md1 && hdparm -t /dev/md1 && hdparm -t /dev/md1 && hdparm -T /dev/md1 && hdparm -T /dev/md1 && hdparm -T /dev/md1
/dev/md1:
/dev/md1:
/dev/md1:
/dev/md1:
/dev/md1:
/dev/md1:
/dev/md1:
/]# hdparm -g /dev/md0 && hdparm -t /dev/md0 && hdparm -t /dev/md0 && hdparm -t /dev/md0 && hdparm -T /dev/md0 && hdparm -T /dev/md0 && hdparm -T /dev/md0
/dev/md0:
/dev/md0:
/dev/md0:
/dev/md0:
/dev/md0:
/dev/md0:
/dev/md0:
The first machine (brainstem) has SCSI Raid-5 with 18 GB drives. The second machine (heschl) has IDE Raid-5 with 120 GB drives. It's used to serve music and pictures (sorry, no pr0n - just digital camera pics) to my local network.
Machine 1 (SCSI)
-----------------
brainstem:~# hdparm -g
geometry = 58240/2/4, sectors = 141499392, start = 0
Timing buffered disk reads: 64 MB in 1.83 seconds = 34.97 MB/sec
Timing buffered disk reads: 64 MB in 1.83 seconds = 34.97 MB/sec
Timing buffered disk reads: 64 MB in 1.83 seconds = 34.97 MB/sec
Timing buffer-cache reads: 128 MB in 0.85 seconds =150.59 MB/sec
Timing buffer-cache reads: 128 MB in 0.86 seconds =148.84 MB/sec
Timing buffer-cache reads: 128 MB in 0.86 seconds =148.84 MB/sec
Machine 2 (IDE)
----------------
[root@heschl
geometry = 42304/2/4, sectors = 937765376, start = 0
Timing buffered disk reads: 64 MB in 3.14 seconds = 20.38 MB/sec
Timing buffered disk reads: 64 MB in 3.24 seconds = 19.75 MB/sec
Timing buffered disk reads: 64 MB in 3.19 seconds = 20.06 MB/sec
Timing buffer-cache reads: 128 MB in 1.09 seconds =117.43 MB/sec
Timing buffer-cache reads: 128 MB in 1.09 seconds =117.43 MB/sec
Timing buffer-cache reads: 128 MB in 1.10 seconds =116.36 MB/sec
Linux - Because Mommy taught me to Share.
Promise RAID is actually a software RAID. Don't let the fancy BIOS thiny fool ya. Here's a little story:
:) Those jokers are REALLY SLOW to recompile their kernel modules.
I had a Promise Ultra 100 controller in a system and loaded Linux on it. I tried to get the thing ot run RedHat 7.3. This was back when 7.3 was pretty new... like about 3 months old. I wanted to use the RAID controller since I had nothing else to do with it at the time and I knew Promise was supporting Linux.
Turns out they didn't have a driver for 7.3... just 7.2. I went around and around with them asking them to recompile the driver for me after I was mentioning the merits of oper sourcing drivers and such. Finally I gave up and bought some Maxtor PCI IDE controller out of the CompUSA bargain bin for like $10. It looked familiar...
I pulled the Promise card out and was about to put the Maxtor card in when I realized they were both the SAME DAMNED CARD! It was then I realized the RAID controller depended on software and not some fancy hardware thing. It was then I understood why Promise doesn't want to open source their driver!
Anyway, I put the bargain controller in and used a Linux software RAID. Short end to the story. I got my RAID and it worked. Better end, it was software and I could configure it using Webmin! That probably what you should do. Let the system see the two drives and then do the Linux software RAID... there is a redhat 7,3 driver out on the promise website... but I don't see a redhat 8.0
Our test of the promise raid under redhat linux with the "open source" drivers (2.4.19 vanilla) compared with the 3ware product were VERY different.
I don't have the exact numbers off hand, but the 3 ware product was roughly 3 times faster at reading (raid 0+1 and raid 1). The 3ware was also faster at writing albeit the numbers were much closer. The number that DOES stick in my head was the postmark benchmark from netapp we ran. The promise did 2500 files, from 2 to 200k with 500 operations in about 35 seconds. The 3ware product did the same in 12.
The moral of the story is TEST TEST TEST, these types of articles only give you an idea. Promise worked great for me personally in several applications. After testing it for a production machine at work, we went with the 3ware because the promise did not perform well for our application. Test for youself, or forever be dissapointed.
Cluge
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
In 1988 SCSI was still bloody cheap compared to, say DASD.
First off, they've failed to note that some of their contestants are in fact just IDE controllers, with the RAID functionality implemented in the software driver (WinRAID, like WinModems), whereas others are Hardware. I don't know all four products well, so I'm unsure on at least one of them as to which are which.
They tested CPU utilization, and seperately various speed tests, but never a comprehensive "loaded system" test. As expected they ranked the Adaptec (a true hardware RAID) lowest, while ranking the WinRAID's higher. This couldn't be further from the real truth. Sure, the idle P4 cpu does a great job of fast software RAID compared to the embedded RAID ASIC on Adaptec's card. However, if you had a heavily loaded server machine, where the processors were loaded down doing other things (say SSL-encrypting for an secure web server), the machine with the Adaptec would trounce the others, as the RAID processing speed will not decrease while your applications are using most of the CPU (or depending on the device driver's pre-emptability, it could be the other way around, that the CPU simply wouldn't be as available to your CPU-hungy SSL server as it's busy with the RAID).
11*43+456^2
I've got 5 servers (one is an Exchange 2000 server) at a school with about 200 users. All servers are running some form of promise ATA raid 1 setup for boot drives and some also use an ATA raid 1 for their data drives. The file server and mail server use Adaptec 2400A raid controllers with four 100GB drives in a RAID 5 configuration. All hard drives are western digital 7200 RPM drives.
No one complains about speed issues. Everything seems to work very well.....at a fraction of the cost of SCSI.
I love the look on visitors' faces when they see our servers have 300-600GB of available storage...for very little cost. (Backing up all that data still requires SCSI tape arrays...not cheap.)
I've had a couple of drives tank on me here and there, but no data loss yet...just replaced the failed drive...rebooted and in about 20 minutes the array was completely rebuilt.
I am a fan of SCSI (got plenty of SCSI raid at my house) but when you've got to stay under a budget, you can't beat ATA raid.
-ted
From the Slashdot story: "I personally would love to hear any ide-raid stories that slashdotters might have." I also would like to hear about this.
Here's my story: I have extensive experience with Promise controllers. An IDE mirror makes data reads faster. If you are about to do a possibly damaging operation, it is good to break the mirror, pull out one of the hard drives, and do the operation on the other drive only. Then, when craziness happens, the other drive is a complete backup.
A mirroring controller is a convenient way to make a Windows XP operating system hard drive clone. Windows XP prevents this; normally third-party software that runs under DOS is needed to make a useable full hard drive backup. See the section "Backup Problems: Windows XP cannot copy some of its own files" in the article Windows XP Shows the Direction Microsoft is Going. (The article was updated today. To all those who have read the article, sorry for the previously poor wording of the section "Hidden Connections". Expect further improvements later in this section later.)
But Promise controllers are quirky. Sometimes things go wrong, and there is no explanation available from Promise. Promise tech support is surprisingly ignorant of the issues. The setup is quirky; it is difficult to train a non-technical person to deal with the controller's interface.
Mirrors are a GREAT idea, but Promise is un-promising. That's my opinion. I'm looking for another supplier, so I want to hear other's stories.
> I don't quite understand where this Inexpensive crap came from.
RAID (Random Array of Inexpensive Disks) was as opposed to SLED
(Single Large Expensive Disk). (The term "Random" means the same
as in RAM -- i.e., that you can access any part (any drive, in this
case) at any time.)
> RAID was around long before IDE RAID controllers started showing
> up and of course SCSI RAID arrays almost always use very expesive
> disks.
"expensive" is relative. (Instead of thinking of SCSI as the only
other option besides RAID, try to remember that there were larger
and more expensive disks at one time.)
> It's Redunant Array of Independent Disks, always has always
> will be.
It's not necessarily "redundant" at all; some RAIDs are done just
for performance reasons, with no redundancy. (Personally, I am
more interested in the redundancy, however.)
Cut that out, or I will ship you to Norilsk in a box.
I've passed this feedback onto the author of the ide raid-roundup - i figured i might as well post it here too.
I just thought i'd share some of my experiences with promise support.
Frankly, they have been terrible. I would not voluntarily buy another promise product again at this stage based on my experience with them.
I have been attempting to get support for the Promise FastTrack which is a popular embedded raid controller option, under Linux.
Promise indeed "support" RedHat but do so with a binary only, closed source module that in the end turns out to be useless.
Promise hard code a supported kernel version for this driver such that you can run it under say RedHat 7.3, but only the initial 2.4.18-3 kernel, which has a number of critical bugs which have been addressed in later (errata) kernel updates.
Needless to say, promise's driver will not run on any later kernel or at least they are unwilling to answer questions on how to do this.
A comparable analogy would be if they had released Windows XP drivers and then your hard drive failed to work if you installed a hot fix or a service pack because the driver is keyed to only the specific intial installed released of XP. Promise don't treat windows users this way, so why do they do this for linux users ?
I've managed to get two responses out of their support, none of which will address my problem - support the hardware under linux by releasing the source or provide updated kernel drivers for the released kernel images that will actually work.
In terms of driver support for Linux/FreeBSD, 3ware wins hands down in this group.
regards,
-jason
Why hasn't the ArcoIDE solution caught on like wildfire? It provides mirrored disk capability with absolutely no visibility to even the motherboard, much less the OS. I've been running it for years and it's great. Mine is the PCI slot model that simply uses the slot to get power to the card. One IDE cable from the motherboard to the card, two cables to the two hard drives.
And there's all sorts of alarming options -- LED's on the card, LED's on a front panel bezel, audible screech, Form C contacts for you industry types ...
I don't get it.
One simple rule for its versus it's
None of my ATA raid controllers requires identical drives. In the case of disimilar capacities, the array views all drives as the smallest drive in the array.
Later on in the life of the array, you can eventually replace the remaining drives and then resize the partition.
-ted
So I was surprised reading the review to see the Adaptec and 3Ware neck and neck in the RAID 5 area. 3Ware's usually have no competition in RAID-5 since their firmware and HW rock.
Then I found out WHY they were so close:
The 3Ware cards are 64-bit cards while the Adaptec's are only 32-bit. 3Ware cards can hit 70MB/sec writing and over 150MBsec reading with 8HD's! If they ever get to 66MHz, I expect their performance to go even higher.
If you want to see better benchmarks that fit with reality, check out the XBit Labs Review
Top Most Bizarre/Disturbing Error Messages
Utilizing eBay and a few vendors that I dug around for, I was able to assemble a blazingly fast fibre channel RAID system for home for around $500. If you take a look at http://www.nuxx.net/gallery/fibrechannel you can see the assembly of the box. There are also benchmarks detailing the RAID 5 array bursting to >160MB/sec (image at http://www.nuxx.net/gallery/fc_benchmarks/aad).
The box is set up as follows:
o Mylex eXtremeRAID 3000 ($200 via eBay)
o Crucial 256MB DIMM for Cache (~$50 from Crucial)
o 4 x Seagate ST39102FC 9GB 10,000 RPM drives ($9/ea on eBay)
o Venus-brand 4-disk external enclosure (~$35 on eBay)
o Custom made FC-AL backplane for disks (~$200 from a site I can't remember at this time)
o 35m FC-AL cable (HSSDCDB9) (~$40 for two on eBay)
The best part? The box is located in my basement, so I have this incredibly fast disk disk access, with no noise and no extra heat inside my case. That also allows me to cool the case more efficiently. Sure, IDE RAID may be cheaper, but the performance, per-disk, coupled with the reduced noise in my office and the reduced heat in the case is a big plus. Also, I might eventually pick up a second backplane for another four disks and do RAID 0+1. Since each channel is capable of 100MB/sec (without caching), the use of a set created across two channels would be amazing.
They're all hooked up to a 3ware Escalade 7500-12 card, RAID5, with a hot spare. Application is storage of large amounts of raw digital images 7-8MB each.
Been going for a few weeks now, no problems, 2.4.19 kernel's built in drivers lights the array right up as sda1.
I would show you more but I'm ssh'd in and the power just went out. The 300VA ups running this box while I'm testing it probably just let its smoke out. Doh.
Anyway I like it. If its not fried.
--------------------------------
Not all who wander, are lost.
I like reading the comments here, I am humble enough to know I can always learn something. But there's something I didn't see mentioned, in all these IDE RAID setups that people describe: can you have a hot spare disk? Hot spare is critical for data reliability. If you have a large RAID 5 or RAID 0+1 (not advised, always do 1+0, whenever possible), you can do the math and see how darn important it is to have the host spare.
What good it is to have a RAID 5 without a hot spare, when you can only guard against single drive failure? So, I really hope IDE RAID supports hot spare, otherwise I question the saity of mind of the admins who implement such solutions.
As for IDE vs SCSI drives, I have to say that I will always go with SCSI, as long as I am in a multuser environment where seek times are critical. Apparently (experience shows), if you put your database space on a RAID, seek times are critical for the performance of your application. In this context, I think this review/coparison would have benefitted from a real-life aplication's benchmarking, with a database hosted on the RAID.
Sigged!
18GB SCSI 10K rpm drive vs 120GB ATA 7200 rpm drive.
;).
Partition 120GB drive so that you only use the fastest 18GB of it.
Now compare random access seek times. Only seeking 15% of 120GB drive
If 120GB ATA drive is too expensive. Test with an 80GB drive.
Not sure what the results will be, but it's worth trying don't you think?
Some drives would probably be better at short seeks than others (settling time etc). Don't see much info on this tho.
There are valid performance and reliability reasons for using SCSI drives instead of IDE drives; the question is whether these gains are worth the cost, not whether they are there at all.
Reasons why SCSI might be worth it:
- Spin rate. Until IDE drives gain 10k and 15k spin rates, SCSI drives will always be king in multitasking and random-access situations. 3ms seek time is so much better than 10ms that you have to use it to believe the difference.
- Reliability. IDE drives have one year or at best three year warranties. SCSI drives have five year warranties. You can run modern 15k scsi drives stacked next to each other with zero additional case fans and expect to outlast your warranty. Try that with IDE.
- Hot swap. Does anyone here know of a hot-swap IDE raid solution? I think not.
- Tagged command queuing. A SCSI drive can collect multiple drive requests and reorder them to optimize the actual physical retrieval of the bits in question. IDE drives, even if the box lists this feature, have never done TCQ particularly well. This kind of thing is impossible to benchmark because its benefits only show up under heavy multitasking, not single-tasking benchmarks.
For most people, I would agree that you would be better off buying 2GB ram or two CPUs before spending money on SCSI. However, if you already have 2GB ram and two CPUs, and you still need more, then that's when you should look into high end SCSI.I've been working on x86-based servers a long, long time.
:-)
There are many reasons one should choose SCSI over IDE, but I want to counter a few of the arguments I've read through the many messages here:
Argument #1:
SCSI can have 15 devices per bus, but why buy more smaller and more expensive SCSI drives instead of getting fewer large IDE drives?
Answer: Bigger isn't always better. On large RAID systems (real servers, here people...not Mp3 servers) one of the concepts of RAID5 is to spread out the data among as many drive spindles as possible. This keeps each drive's load level under control, and eliminates hot-spots on individual disks. If you sit down with any SAN vendor, like EMC, they will tell you the same thing.
Argument #2
Sustained IDE Raid performance can equal SCSI
This is absolutely incorrect. This may be true on a server with no CPU load. Try this again on a server running SQL and averaging 85% load. You will NOT see the same performance out of an IDE disk layer. There is simply too much CPU overhead on an IDE-based RAID system for heavy-load systems. The idea behind a SCSI controller is that it is free of the system's CPU as a bottleneck. The money saved on non-SCSI hardware will instead need to be spent on faster CPUs.
Argument #3
IDE Disks are just as reliable as SCSI
Again, completely false. You get what you pay for. SCSI disks have logic on each disk to control the operations OF that disk. In a RAID array, you want each disk to be completely independant of the others. IDE RAID requires the controller to do all the monitoring (if there is any) of each disk, lowering performance of its primary function--controlling disk I/O. Anyone who has worked on a Compaq server and used Insight Manager will be able to see the advantages of SCSI disks directly. SCSI disks will be more reliable since they are built to be more reliable. IDE disks are meant for cheap deployment on cheap systems.
Thank you, have a nice day
-brain