It goes further than that. US government research has shown that drivers tend to naturally drive at a speed they feel is safe and that there is a strong correlation among drivers. If posted speed limits are within reason, drivers tend to respect them but otherwise tend to ignore them. In the US, posted speed limits are set around the 35th percentile of drivers and are commonly 10-15 MPH slower than safe under good conditions. If local government wants more revenue it lowers speed limits and creates a ready supply of willing violators. This should surprise no one, yet some would believe this to be the basis for insurance rates?
I'd like to see the results of monitoring of a typical traffic cop since I've never seen one with any respect for posted speeds or traffic laws in general. Are we to believe that traffic cops are our worst drivers? Fact is that many are. In Texas, only our DPS (state troopers) are actually required to pass a competancy test on traffic laws before they're sent out to enforce them. Says a lot, doesn't it.
No they aren't. Insurance companies are trying to maximize profits using divide and conquer.
The whole concept of insurance is that everyone "subsidizes the rates" by sharing equally in the risk. Insurance works best when it has a large pool of insured to draw from and doesn't discriminate. The whole concept of isolating people at risk is to drive profits up and playing to the ego of the "good driver" is one way they accomplish it. You buy into the entitlement of special rates because you're so good, then something happens that's unforeseen and you're instantly screwed. Insurance isn't supposed to work like that.
The proper answer to this proposal is "fuck off" but it won't happen. Slow drivers actually think they're safer than fast drivers, though in my experience that is far from true. All they really need to do the job is a device that detects the overlap between driving and cell phone use. Drop anyone above a certainly percentage.
I didn't know we were building our systems out of salvaged parts!:)
Cables are an insignificant cost in the grand scheme of things. A SATA cable is about $4, less than the tax on the drive it connects to.
Adding a controller is not an issue either considering you will be doing the same with SCSI. My newest motherboard takes 6 IDE drives directly and 6 more through a controller I added for about $300. It's typical of what's available. Boards designed for small boxes may have less but the boxes don't take more anyway. If you want to make a RAID box with large disk counts you should be looking for a larger box and a motherboard that supports the devices. Not hard to find.
My new box consists of 6 300GB drives connected to a SATA controller at a cost of about $1500 (under $1 per GB). Everything else is strictly an ATX PC (although I'm using two SATA drives for the system as an experiment). I need about 1.5TB in order to rsync all my backup needs in one location and this allows me to replace multiple backup boxes.
Anyway, you make good points and I'm not sure that I disagree with them. I think the differences are in what we are talking about. Part of this is the performance value of RAID on the desktop of which I don't think there is too much. Part of this is SCSI vs. IDE where I think SCSI used to be clearly the answer but SATA and SAS a clearly the future. It's easy enough to find superior SCSI-based RAID products in the past since it owned (and still does) the midrange market. In the future, the higher end will move increasingly toward NAS with SAN's continuing to use FC until something like PCIe AS can displace it. SCSI won't play there. Internally all these boxes will use SATA or SAS for their connections. Parallel SCSI doesn't have a future in the high end and it has no appeal in the low end as SATA and SAS take it easily there. SCSI served us well for a long time but serial, point-to-point coonections are the future for disks just as they are in networking, processor and peripheral interconnects.
You must not develop storage products, then, as I did. In a previous lifetime I developed SCSI RAID controllers and am quite familiar with all the failure modes of conventional SCSI busses. Since a SCSI drive is electrically connected to the bus it can cause the bus to cease functioning at any time just by, say, shorting all the pins. This is not a far-fetched situation. Blowing an interface chip in a drive can lock a SCSI bus permanently. The proper way to design an availability system is with point to point connections, not shared busses. Seen any 10Base2 networks deployed recently?
DEC StorageWorks was a nicely done product. We eval'ed it before doing our own. SCSI hotplug is not trivial from an electrical standpoint and many fail to do it well. DEC was not one of those.
Modern motherboards today frequently come with two IDE channels supporting four devices and two or even four SATA ports as well. You are free to add SATA or ATA cards and there are 12 port SATA cards available. I don't think IDE limits a desktop or any other system to 2 drives and it hasn't for a long time. Building a parallel IDE system with a large number of drives is a pain but SATA makes it easy. I'm building an 8 drive SATA desktop as we speak. Needing some rsync space.
Also remember that Win95 was developed with Plug and Play, a very ambitious effort on MS's part. MS drove ISAPnP as a new standard, heavily influenced PCI, and even got monitor and video manufacturers to implement new PnP standards. The work required of system vendors was enormous as the changes necessary to support PnP were huge. Win95 was a monumental effort and some of the technical fallout from it benefits mac users today.
And don't forget Apple's position that "there's no place for color in a computer system". How long did it take for Apple to introduce a mac with color? PC users had no monopoly on dumbass opinions. Hell, some of them exist in OS X today.
Most screens weren't CGA back then, either. Most PC's had Monochrome adapters or Hercules.
The reason Jobs won't port OS X is that he's done it and failed already, at NeXT.
The clone CGA cards didn't suffer from snow. I had a real IBM one that did, but I don't recall (and don't believe) any snow issues in the graphics modes. It's true you wouldn't want to run a GUI on one, though. The EGA was quite nice in its day.
OS/2 was the intended operating system for the AT and had a long development time. By the time it shipped, it did so without the GUI and the 386 was already shipping. Still, the 386 didn't exist when IBM and MS made their design commitments.
While you are blaming IBM for OS/2 and the 286, don't forget that IBM is to blame for the lame 286 itself. They heavily drove its design and are responsible for the CPU being unable to switch itself out of protect mode. Intel figured the x86 was dead and was developing the 960 as its 32 bit processor. Only later did Intel (a) realize it needed to do the 386, and (b) that they couldn't afford to let IBM screw it up.
If was odd at the time that Windows/386 could do far more with DOS programs than OS/2.
The EGA came out in, what, 1985? Soon after were EGA480 cards with square pixels and the first multisync monitor.
The Atari ST ran GEM which was also available on the PC. One of my college jobs was porting TeX to it which turned out to be quite easy. The ST was a pretty nice machine.
OS/2 1.1 came out much earlier than 1995 as well and it didn't suck. While it wasn't called Windows it was given a Windows version number by MS. It was certainly intended to be the Windows followon at one time.
Yes, exactly! While technically not Windows, OS/2 1.1 didn't suck according to many and was much earlier than 1995. IBM had Deskview and DR had GEM far earlier but lost out to Windows. Both ran on top of DOS. MS had a fully virtualized, fully preemptive version of Windows (Windows/386) in 87 or 88. Macs followed a decade later.
Another bone I'd pick with the article was stating that PC's of the day were limited to 320x240 graphics. Fact is there was never a PC so limited. Text mode PC's had no graphics at all but all others were better and the EGA (85?) was far better than what mac offered. Hardware was no impediment to implementing a GUI on PC's in those days.
I wasn't considering dedicated appliances like NetApp with my software RAID statement. I was thinking more along the lines of Linux/Windows/BSD software RAID. These days there's really only software RAID and which side of the interface you are on determines whether you call it hardware or not.
IDE doesn't limit you to a two drive system. Ideally you want a point-to-point connection in any high availability system anyway, so SCSI busses are strictly a compromise and many SCSI RAID products have high bus counts for orthogonality. Having worked on SCSI RAID controllers I can tell you that when a SCSI drive fails it can take the bus with it quite easily. Hot plugging SCSI is a scary thing as well and many manufacturers don't get it right.
The future of SCSI is SAS which adopts SATA's physical layer (thank God). You will be able to attach a SAS drive or a SATA drive (provided the controller does both) and have it just work. Very cool! Bye bye fibre channel and good riddance. Of course, it's point-to-point but both interfaces will allow switches.
I seriously doubt any system connects its software RAID with its filesystem layout to optimize performance. I could be wrong but I'd need proof before I believed it. No doubt that software RAID allows you some flexibility. I'm quite a big fan of it but I'd rather have the ability to add multiple partitions into a single filesystem at format-time and let the fs distribute data dynamically. That would be far more interesting!
I believe that NetApp runs a standard RAID array underneath WAFL. Not very knowledgable on them, but that's where I find criticism with everything. You own the filesystem and the devices so why do you split the striping, reduandancy and metadata apart? That can only be a loss, never a win.
Technically, yes IDE has implemented those things but I understand your point. Command queuing and disconnect are not valuable on a point-to-point connection however and scatter gather has been performed by IDE drivers for some time. Regardless, you can't argue that those features are essential (save SG) for a high performance interface unless you have a shared bus (which SCSI is and IDE is not). SATA 2 introduces share links, switching a queuing, BTW. Keeping these things sorted inside a driver is no big deal at all.
Of course sparing is essential and there's no way around it when using RAID. I firmly believe there are better solutions than RAID and hot/cold spares can go away in favor of fully active devices with distributed reserved capacity instead. Hot spares actually reduce system MTBF although they increase mean time to data loss by minimizing MTTR as you said.
Yes, I did read the HOWTO. It's dated and filled with basic knowledge but is a useful resource.
The purpose of RAID is not necessarily to get multiple disk drives to simultaneously participate in a single IO. Most disk loads don't allow for that since the typical IO size is too low (as you've observed). On the other hand, if you are doing IO on lots of files at the same time multiple disk drives can satisfy unrelated IO's in a manner that greatly improves aggregate throughput. The bulk of all RAID configurations target this case. That is why stripe sizes are typically 64K-256K.
Any OS "trick" that results in improved performance is simply a workaround for the OS not getting it right in the first place. I doubt seriously that having swap software interleaved results in significantly better performance than putting swap on a RAID 0 device of identical devices. I see no reason why it would be worse, either, since the operation is similar in each case.
Old news servers stored each article as a file. Doing so bottlenecks the machine of fs metadata operations. Clearly, fringe applications like this can cause excessive IO imbalance even in multidrive systems if you aren't careful. The proper solution is not to use such a crappy news server. Years ago I ran INN on FreeBSD with a 3 drive RAID 0 and had no problem keeping up with a 100Mb direct feed. Today the volume is much larger but drives and processors are faster, too, and I was told that there was no way I could keep up with a full feed at that time. News servers are simply an example of a poor implementation making it difficult to go fast.
That depends on what is meant by "released". Released to whom? I'm certainly a productive programmer but none of it is "open source" in RMS terms (though some is public domain). Regardless, his productivity is unrelated to his motivation and making his source available in no way diminishes his desire to coerce others to do the same. The point is that RMS is just as motivated out of self-interest as others, it's just in his case money isn't the interest. That's easy for RMS considering that his way has always been paid for him.
Furthermore, Dell's not attempting to break into this market (reviewer stating so beside the point). Dell's been making these kind of machines for quite a while and it's unlikely that Dell cares one way or another about Alienware. Dell's entire Dimension brand was created for these types of customers and has existed for a decade, far longer than Alienware. Only difference is today's kids are familiar with Alienware's flash. Once you get past the fancy case, parts is parts.
Dell sells to large accounts and has always been good at making those customers happy. People who know "that" buy Dell as evidenced by their market domination.
Dell has always considered the home market as secondary. Your description of Johnny is more applicable to Alienware than Dell.
This is incorrect. RAID 1 would be faster than RAID 0 for read workloads where there was (1) sufficient command queue depth, and (2) a castrophic inbalance in the workload that prevented the RAID 0 drive from utilizing its disks. Since the second case never happens (except in improper configurations), RAID 0 will outperform RAID 1 with identical numbers of disks. RAID 1 can have more than two disks (requires and even number) although some foolishly believe that striping in RAID 1 makes it RAID 10 or 1+0 or 0+1. Please read Patterson.
Assuming a two drive RAID 1 versus RAID 0 in a small random read environment with sufficient queue depth, the RAID 0 array provides twice the working capacity of the RAID 1 and therefore its relative seek distances are smaller. Remember that the data set and IO sizes don't change simply because the array is larger. The RAID 0 array will still see full utilization of both spindles due to the random access nature and sufficient queue depth. The array is faster for the same reason that a 200GB 2 platter drive is faster than its 100GB 1 platter stablemate. Less cylinder switches and shorter seeks.
There seems to be this myth that RAID is only for accelerating large sequential transfers. Nothing is further from the truth. Random IO workloads constitute the bulk of all RAID applications and RAID 0 is king of performance with identical drive counts. When RAID 1 is characterized as faster than RAID 0 it is referring to identical "data drive" counts.
Except that the probability of failure of any one drive is impacted by the existence of the other drives and other components in the system. Because of that, your simple equation doesn't apply. Ultimately you system will fail at it's weakest point and the existence of RAID 0 doesn't make your extra disk the weak point.
Recently I lost a drive in my main home server that consisted of 7 Maxtor 160's, one boot and one 6 drive RAID 0. It was the boot drive that failed, of course, and that turned out to be a blessing. Why did it fail rather than the others? Who knows, but it was mounted in the chassis in an area with less airflow than the other drives. A new drive, a clean install and a monstrous fsck and my entire library was back live.
It doesn't work like that in the real world though. First, the odds of a disk failure are miniscule compared to your numbers. Second, the odds of disk failure are proportional to heat and the odds of a fan failure are one or two orders of magnitude greater than a disk failure. If your setup is dependent on a fan keeping your disks cool enough, then the odds of a disk failure with two disks are probably no greater than one disk. The bad news is that those odds are about 1 in 1. In other words, reliability doesn't really go down even if the numbers suggest it does.
The thing with RAID is that it exists underneath the filesystem. That means the filesystem doesn't know it exists and will not optimize layout because of it. It's possible to add this through "hints" or out-of-band config info but that's not the same as the real thing.
Fact is that RAID is the best you can do when you can't plug into the filesystem. Once you can, RAID becomes the thing you DON'T want to do for just the argument you make. If the filesystem knew it had multiple disk drives to lay a single FS image on it could do so transparently by embedding striping in the FS metadata itself. This would allow dynamic optimization of layout on a file-by-file basis. The fact that this is so seldom done is a condemnation of the computing industry, although I'm aware that Novell did some of this with NetWare back in the 80's.
I agree with your observations, although I don't agree that IDE imposes any limitations you suggest other than number of drives you can conveniently attach. As for "every spindle you add to your system will add performance" how true! Unless you add hot spares, of course. That's why I hate hot spares. They're extra work, extra cost, extra heat, extra failure points and in the end they don't do squat for performance. There's a better way.
Small random reads (and writes) absolutely suit a RAID 0 config provided you have enough of them at the same time. This is the primary means of acceleration in server systems. On the other hand, configurations that are designed to accelerate large sequential IO are in the minority.
Clever partitioning is a way to work around operating system deficiencies. After all, you can't hold a disk drive responsible for the OS'es inability to use it. Tricks to improve filesystem performance are all good but are complimentary to good hardware, not competition for it.
The author produces a lot of words but shows remarkably poor insight. Examples his lack of understanding between sequential access arrays and parallel IO arrays in the introduction, the poor showing of the RAID 5 tests (conveniently avoiding writes in those tests), the difference between RAID techniques and caching, and the association of PCI as the performance limiter in the Promise controller.
The fact is that the article readily admits that desktop workloads show poor average IOps (under 1.5) and modest average IO size (23K). Those numbers prove that there is little opportunity to accelerate performance either with parallel access or random access designs. The first tests show clearly that the IO sizes in question leave little opportunity for large transfer gains while the lack of decent command queue depths rules out good load balance with larger stripe sizes. Interestingly, the author didn't provide the stripe size for that test. It's easy to deduce from the chart but it demonstrates his limited grasp of the subject matter.
Regarding the tests dispelling the myth of poor RAID 5 performance, hardly! Poor RAID 5 performance is no myth. First off, the RAID 5 configuration was trounced by lesser RAID 0 IDE drives. Second, the benchmarks consistently avoided writes, notably small writes, where RAID 5 massively fails, and uses a large writeback cache to further hide write performance and to cause the configuration to shine is small read tests. If you are going to sing the praises of RAID 5 for data protection you should probably mention the data integrity disaster that writeback caches introduce. If I were offering the RAID 5 config myself I would feel like I just got my ass kicked.
Ultimately this article is nothing other that a rant by someone who disagrees with others' contention that RAID 0 is of limited benefit. He justifies his position by saying that performance matters when "performance matters", that is specifically when you create disk-intensive loads you can see a benefit. Well, no shit. When you create large command queue depths through multiple disk-intensive processes then you will benefit. Again, no shit. Boot times can get shaved a little. Big deal. Beyond that he doesn't know what he talking about. There's a big difference between RAID 0 being theoretically capable of superior performance and it being a performance value to a desktop user. This is a subjective matter and he fails to make his case. Just how often does he or any other "power user" actually benefit from these unusual workloads and is that often enough to justify the costs?
Slashdot Mirror
It goes further than that. US government research has shown that drivers tend to naturally drive at a speed they feel is safe and that there is a strong correlation among drivers. If posted speed limits are within reason, drivers tend to respect them but otherwise tend to ignore them. In the US, posted speed limits are set around the 35th percentile of drivers and are commonly 10-15 MPH slower than safe under good conditions. If local government wants more revenue it lowers speed limits and creates a ready supply of willing violators. This should surprise no one, yet some would believe this to be the basis for insurance rates?
I'd like to see the results of monitoring of a typical traffic cop since I've never seen one with any respect for posted speeds or traffic laws in general. Are we to believe that traffic cops are our worst drivers? Fact is that many are. In Texas, only our DPS (state troopers) are actually required to pass a competancy test on traffic laws before they're sent out to enforce them. Says a lot, doesn't it.
No they aren't. Insurance companies are trying to maximize profits using divide and conquer.
The whole concept of insurance is that everyone "subsidizes the rates" by sharing equally in the risk. Insurance works best when it has a large pool of insured to draw from and doesn't discriminate. The whole concept of isolating people at risk is to drive profits up and playing to the ego of the "good driver" is one way they accomplish it. You buy into the entitlement of special rates because you're so good, then something happens that's unforeseen and you're instantly screwed. Insurance isn't supposed to work like that.
The proper answer to this proposal is "fuck off" but it won't happen. Slow drivers actually think they're safer than fast drivers, though in my experience that is far from true. All they really need to do the job is a device that detects the overlap between driving and cell phone use. Drop anyone above a certainly percentage.
I didn't know we were building our systems out of salvaged parts! :)
Cables are an insignificant cost in the grand scheme of things. A SATA cable is about $4, less than the tax on the drive it connects to.
Adding a controller is not an issue either considering you will be doing the same with SCSI. My newest motherboard takes 6 IDE drives directly and 6 more through a controller I added for about $300. It's typical of what's available. Boards designed for small boxes may have less but the boxes don't take more anyway. If you want to make a RAID box with large disk counts you should be looking for a larger box and a motherboard that supports the devices. Not hard to find.
My new box consists of 6 300GB drives connected to a SATA controller at a cost of about $1500 (under $1 per GB). Everything else is strictly an ATX PC (although I'm using two SATA drives for the system as an experiment). I need about 1.5TB in order to rsync all my backup needs in one location and this allows me to replace multiple backup boxes.
Anyway, you make good points and I'm not sure that I disagree with them. I think the differences are in what we are talking about. Part of this is the performance value of RAID on the desktop of which I don't think there is too much. Part of this is SCSI vs. IDE where I think SCSI used to be clearly the answer but SATA and SAS a clearly the future. It's easy enough to find superior SCSI-based RAID products in the past since it owned (and still does) the midrange market. In the future, the higher end will move increasingly toward NAS with SAN's continuing to use FC until something like PCIe AS can displace it. SCSI won't play there. Internally all these boxes will use SATA or SAS for their connections. Parallel SCSI doesn't have a future in the high end and it has no appeal in the low end as SATA and SAS take it easily there. SCSI served us well for a long time but serial, point-to-point coonections are the future for disks just as they are in networking, processor and peripheral interconnects.
You must not develop storage products, then, as I did. In a previous lifetime I developed SCSI RAID controllers and am quite familiar with all the failure modes of conventional SCSI busses. Since a SCSI drive is electrically connected to the bus it can cause the bus to cease functioning at any time just by, say, shorting all the pins. This is not a far-fetched situation. Blowing an interface chip in a drive can lock a SCSI bus permanently. The proper way to design an availability system is with point to point connections, not shared busses. Seen any 10Base2 networks deployed recently?
DEC StorageWorks was a nicely done product. We eval'ed it before doing our own. SCSI hotplug is not trivial from an electrical standpoint and many fail to do it well. DEC was not one of those.
Modern motherboards today frequently come with two IDE channels supporting four devices and two or even four SATA ports as well. You are free to add SATA or ATA cards and there are 12 port SATA cards available. I don't think IDE limits a desktop or any other system to 2 drives and it hasn't for a long time. Building a parallel IDE system with a large number of drives is a pain but SATA makes it easy. I'm building an 8 drive SATA desktop as we speak. Needing some rsync space.
Also remember that Win95 was developed with Plug and Play, a very ambitious effort on MS's part. MS drove ISAPnP as a new standard, heavily influenced PCI, and even got monitor and video manufacturers to implement new PnP standards. The work required of system vendors was enormous as the changes necessary to support PnP were huge. Win95 was a monumental effort and some of the technical fallout from it benefits mac users today.
And don't forget Apple's position that "there's no place for color in a computer system". How long did it take for Apple to introduce a mac with color? PC users had no monopoly on dumbass opinions. Hell, some of them exist in OS X today.
Most screens weren't CGA back then, either. Most PC's had Monochrome adapters or Hercules.
The reason Jobs won't port OS X is that he's done it and failed already, at NeXT.
The clone CGA cards didn't suffer from snow. I had a real IBM one that did, but I don't recall (and don't believe) any snow issues in the graphics modes. It's true you wouldn't want to run a GUI on one, though. The EGA was quite nice in its day.
OS/2 was the intended operating system for the AT and had a long development time. By the time it shipped, it did so without the GUI and the 386 was already shipping. Still, the 386 didn't exist when IBM and MS made their design commitments.
While you are blaming IBM for OS/2 and the 286, don't forget that IBM is to blame for the lame 286 itself. They heavily drove its design and are responsible for the CPU being unable to switch itself out of protect mode. Intel figured the x86 was dead and was developing the 960 as its 32 bit processor. Only later did Intel (a) realize it needed to do the 386, and (b) that they couldn't afford to let IBM screw it up.
If was odd at the time that Windows/386 could do far more with DOS programs than OS/2.
The EGA came out in, what, 1985? Soon after were EGA480 cards with square pixels and the first multisync monitor.
The Atari ST ran GEM which was also available on the PC. One of my college jobs was porting TeX to it which turned out to be quite easy. The ST was a pretty nice machine.
OS/2 1.1 came out much earlier than 1995 as well and it didn't suck. While it wasn't called Windows it was given a Windows version number by MS. It was certainly intended to be the Windows followon at one time.
Yes, exactly! While technically not Windows, OS/2 1.1 didn't suck according to many and was much earlier than 1995. IBM had Deskview and DR had GEM far earlier but lost out to Windows. Both ran on top of DOS. MS had a fully virtualized, fully preemptive version of Windows (Windows/386) in 87 or 88. Macs followed a decade later.
Another bone I'd pick with the article was stating that PC's of the day were limited to 320x240 graphics. Fact is there was never a PC so limited. Text mode PC's had no graphics at all but all others were better and the EGA (85?) was far better than what mac offered. Hardware was no impediment to implementing a GUI on PC's in those days.
I wasn't considering dedicated appliances like NetApp with my software RAID statement. I was thinking more along the lines of Linux/Windows/BSD software RAID. These days there's really only software RAID and which side of the interface you are on determines whether you call it hardware or not.
IDE doesn't limit you to a two drive system. Ideally you want a point-to-point connection in any high availability system anyway, so SCSI busses are strictly a compromise and many SCSI RAID products have high bus counts for orthogonality. Having worked on SCSI RAID controllers I can tell you that when a SCSI drive fails it can take the bus with it quite easily. Hot plugging SCSI is a scary thing as well and many manufacturers don't get it right.
The future of SCSI is SAS which adopts SATA's physical layer (thank God). You will be able to attach a SAS drive or a SATA drive (provided the controller does both) and have it just work. Very cool! Bye bye fibre channel and good riddance. Of course, it's point-to-point but both interfaces will allow switches.
I seriously doubt any system connects its software RAID with its filesystem layout to optimize performance. I could be wrong but I'd need proof before I believed it. No doubt that software RAID allows you some flexibility. I'm quite a big fan of it but I'd rather have the ability to add multiple partitions into a single filesystem at format-time and let the fs distribute data dynamically. That would be far more interesting!
I believe that NetApp runs a standard RAID array underneath WAFL. Not very knowledgable on them, but that's where I find criticism with everything. You own the filesystem and the devices so why do you split the striping, reduandancy and metadata apart? That can only be a loss, never a win.
Technically, yes IDE has implemented those things but I understand your point. Command queuing and disconnect are not valuable on a point-to-point connection however and scatter gather has been performed by IDE drivers for some time. Regardless, you can't argue that those features are essential (save SG) for a high performance interface unless you have a shared bus (which SCSI is and IDE is not). SATA 2 introduces share links, switching a queuing, BTW. Keeping these things sorted inside a driver is no big deal at all.
Of course sparing is essential and there's no way around it when using RAID. I firmly believe there are better solutions than RAID and hot/cold spares can go away in favor of fully active devices with distributed reserved capacity instead. Hot spares actually reduce system MTBF although they increase mean time to data loss by minimizing MTTR as you said.
Yes, I did read the HOWTO. It's dated and filled with basic knowledge but is a useful resource.
The purpose of RAID is not necessarily to get multiple disk drives to simultaneously participate in a single IO. Most disk loads don't allow for that since the typical IO size is too low (as you've observed). On the other hand, if you are doing IO on lots of files at the same time multiple disk drives can satisfy unrelated IO's in a manner that greatly improves aggregate throughput. The bulk of all RAID configurations target this case. That is why stripe sizes are typically 64K-256K.
Any OS "trick" that results in improved performance is simply a workaround for the OS not getting it right in the first place. I doubt seriously that having swap software interleaved results in significantly better performance than putting swap on a RAID 0 device of identical devices. I see no reason why it would be worse, either, since the operation is similar in each case.
Old news servers stored each article as a file. Doing so bottlenecks the machine of fs metadata operations. Clearly, fringe applications like this can cause excessive IO imbalance even in multidrive systems if you aren't careful. The proper solution is not to use such a crappy news server. Years ago I ran INN on FreeBSD with a 3 drive RAID 0 and had no problem keeping up with a 100Mb direct feed. Today the volume is much larger but drives and processors are faster, too, and I was told that there was no way I could keep up with a full feed at that time. News servers are simply an example of a poor implementation making it difficult to go fast.
That depends on what is meant by "released". Released to whom? I'm certainly a productive programmer but none of it is "open source" in RMS terms (though some is public domain). Regardless, his productivity is unrelated to his motivation and making his source available in no way diminishes his desire to coerce others to do the same. The point is that RMS is just as motivated out of self-interest as others, it's just in his case money isn't the interest. That's easy for RMS considering that his way has always been paid for him.
Furthermore, Dell's not attempting to break into this market (reviewer stating so beside the point). Dell's been making these kind of machines for quite a while and it's unlikely that Dell cares one way or another about Alienware. Dell's entire Dimension brand was created for these types of customers and has existed for a decade, far longer than Alienware. Only difference is today's kids are familiar with Alienware's flash. Once you get past the fancy case, parts is parts.
People who know what?
Dell sells to large accounts and has always been good at making those customers happy. People who know "that" buy Dell as evidenced by their market domination.
Dell has always considered the home market as secondary. Your description of Johnny is more applicable to Alienware than Dell.
Hardly. Lambo is now owned by Audi however.
Hope you aren't suggesting putting swap on a RAID 5 array.
Funny, I just turn restore off.
This is incorrect. RAID 1 would be faster than RAID 0 for read workloads where there was (1) sufficient command queue depth, and (2) a castrophic inbalance in the workload that prevented the RAID 0 drive from utilizing its disks. Since the second case never happens (except in improper configurations), RAID 0 will outperform RAID 1 with identical numbers of disks. RAID 1 can have more than two disks (requires and even number) although some foolishly believe that striping in RAID 1 makes it RAID 10 or 1+0 or 0+1. Please read Patterson.
Assuming a two drive RAID 1 versus RAID 0 in a small random read environment with sufficient queue depth, the RAID 0 array provides twice the working capacity of the RAID 1 and therefore its relative seek distances are smaller. Remember that the data set and IO sizes don't change simply because the array is larger. The RAID 0 array will still see full utilization of both spindles due to the random access nature and sufficient queue depth. The array is faster for the same reason that a 200GB 2 platter drive is faster than its 100GB 1 platter stablemate. Less cylinder switches and shorter seeks.
There seems to be this myth that RAID is only for accelerating large sequential transfers. Nothing is further from the truth. Random IO workloads constitute the bulk of all RAID applications and RAID 0 is king of performance with identical drive counts. When RAID 1 is characterized as faster than RAID 0 it is referring to identical "data drive" counts.
Except that the probability of failure of any one drive is impacted by the existence of the other drives and other components in the system. Because of that, your simple equation doesn't apply. Ultimately you system will fail at it's weakest point and the existence of RAID 0 doesn't make your extra disk the weak point.
Recently I lost a drive in my main home server that consisted of 7 Maxtor 160's, one boot and one 6 drive RAID 0. It was the boot drive that failed, of course, and that turned out to be a blessing. Why did it fail rather than the others? Who knows, but it was mounted in the chassis in an area with less airflow than the other drives. A new drive, a clean install and a monstrous fsck and my entire library was back live.
It doesn't work like that in the real world though. First, the odds of a disk failure are miniscule compared to your numbers. Second, the odds of disk failure are proportional to heat and the odds of a fan failure are one or two orders of magnitude greater than a disk failure. If your setup is dependent on a fan keeping your disks cool enough, then the odds of a disk failure with two disks are probably no greater than one disk. The bad news is that those odds are about 1 in 1. In other words, reliability doesn't really go down even if the numbers suggest it does.
The thing with RAID is that it exists underneath the filesystem. That means the filesystem doesn't know it exists and will not optimize layout because of it. It's possible to add this through "hints" or out-of-band config info but that's not the same as the real thing.
Fact is that RAID is the best you can do when you can't plug into the filesystem. Once you can, RAID becomes the thing you DON'T want to do for just the argument you make. If the filesystem knew it had multiple disk drives to lay a single FS image on it could do so transparently by embedding striping in the FS metadata itself. This would allow dynamic optimization of layout on a file-by-file basis. The fact that this is so seldom done is a condemnation of the computing industry, although I'm aware that Novell did some of this with NetWare back in the 80's.
I agree with your observations, although I don't agree that IDE imposes any limitations you suggest other than number of drives you can conveniently attach. As for "every spindle you add to your system will add performance" how true! Unless you add hot spares, of course. That's why I hate hot spares. They're extra work, extra cost, extra heat, extra failure points and in the end they don't do squat for performance. There's a better way.
Small random reads (and writes) absolutely suit a RAID 0 config provided you have enough of them at the same time. This is the primary means of acceleration in server systems. On the other hand, configurations that are designed to accelerate large sequential IO are in the minority.
Clever partitioning is a way to work around operating system deficiencies. After all, you can't hold a disk drive responsible for the OS'es inability to use it. Tricks to improve filesystem performance are all good but are complimentary to good hardware, not competition for it.
The author produces a lot of words but shows remarkably poor insight. Examples his lack of understanding between sequential access arrays and parallel IO arrays in the introduction, the poor showing of the RAID 5 tests (conveniently avoiding writes in those tests), the difference between RAID techniques and caching, and the association of PCI as the performance limiter in the Promise controller.
The fact is that the article readily admits that desktop workloads show poor average IOps (under 1.5) and modest average IO size (23K). Those numbers prove that there is little opportunity to accelerate performance either with parallel access or random access designs. The first tests show clearly that the IO sizes in question leave little opportunity for large transfer gains while the lack of decent command queue depths rules out good load balance with larger stripe sizes. Interestingly, the author didn't provide the stripe size for that test. It's easy to deduce from the chart but it demonstrates his limited grasp of the subject matter.
Regarding the tests dispelling the myth of poor RAID 5 performance, hardly! Poor RAID 5 performance is no myth. First off, the RAID 5 configuration was trounced by lesser RAID 0 IDE drives. Second, the benchmarks consistently avoided writes, notably small writes, where RAID 5 massively fails, and uses a large writeback cache to further hide write performance and to cause the configuration to shine is small read tests. If you are going to sing the praises of RAID 5 for data protection you should probably mention the data integrity disaster that writeback caches introduce. If I were offering the RAID 5 config myself I would feel like I just got my ass kicked.
Ultimately this article is nothing other that a rant by someone who disagrees with others' contention that RAID 0 is of limited benefit. He justifies his position by saying that performance matters when "performance matters", that is specifically when you create disk-intensive loads you can see a benefit. Well, no shit. When you create large command queue depths through multiple disk-intensive processes then you will benefit. Again, no shit. Boot times can get shaved a little. Big deal. Beyond that he doesn't know what he talking about. There's a big difference between RAID 0 being theoretically capable of superior performance and it being a performance value to a desktop user. This is a subjective matter and he fails to make his case. Just how often does he or any other "power user" actually benefit from these unusual workloads and is that often enough to justify the costs?