What makes you a geek?

[Concillian]

It definitely does make a difference to running no raid. When you write data in raid 0, you are writing a number of bits across the the number of drives equal to 8 / # drives simulatneously, so with 4 drives, you are writing a byte across those 4 drives in the time it takes to write 2 bits. Yes, there's some overhead that the controller deals with, but saying that it doesn't improve transfer rates is a misnomer.

I specifically said it improves transfer rates. Increasing transfer rates by 50% or even 100% is not a large real world performance benefit. A very large portion of average transactions is latency, which is the large advantage of SSDs. Real world benchmarks with RAID have proved this in every review I've seen that bothers to test beyond using a synthetic benchmark or doing tests which are essentially equivalent to a synthetic sequential read test. My own experience with RAID 5 and a hardware RAID controller also left me with no actual perception of speed improvement.

Here is a pretty in-depth article on reasonably real-world benchmarks. A little old, but nothing has changed that will change the conclusion: http://www.storagereview.com/articles/2004...html?page=0%2C5
The conclusion:

3. RAID helps multi-user applications far more than it does single-user scenarios. The enthusiasm of the power user community combined with the marketing apparatus of firms catering to such crowds has led to an extraordinarily erroneous belief that striping data across two or more drives yields significant performance benefits for the majority of non-server uses. This could not be farther from the truth! Non-server use, even in heavy multitasking situations, generates lower-depth, highly-localized access patterns where read-ahead and write-back strategies dominate. Theory has told those willing to listen that striping does not yield significant performance benefits. Some time ago, a controlled, empirical test backed what theory suggested. Doubts still lingered- irrationally, many believed that results would somehow be different if the array was based off of an SATA or SCSI interface. As shown above, the results are the same. Save your time, money and data- leave RAID for the servers!

When considering the initial point I was making (that SAS is a non factor to home users because the solution I outlined outperforms SAS in every way and also costs less), moving to RAID also will increase latency. Latency is a large factor in the end-user perception of speed. Consider that drives have somewhere around 100 MB / sec internal transfer rates, some are faster, but this is a nice round number.

Consider transfer of a relatively large file for the average user... 1MB, this would take 10 ms ( 1 MB / 100MB / sec = 0.010 sec). But the drive must find the spot on the drive where the data is first. Average seek times are on the order of 5-10 ms for 15k RPM drives and 10-15 ms for 7200 RPM drives. In an ideal world, only one seek is necessary, but in real life, you have fragmented files that may require 2 or 3 seeks until it's done.

So in a best case, user perceived transfer speed is about 50 / 50 on transfer and latency. In reality it's somewhere between that and 75 / 25 (with 75 being seek latency)

RAID 0 doubles the transfer rate, but generally gives a very small penalty to seek latency, we can assume this zero for the sake of argument. Still, moving from a 15k SAS to a 7200 RPM or even a 10k RPM SATA setup will increase latency by 50-100%, for what could be a net zero benefit over SAS, to a potential downgrade vs. 15k SAS.

SSD removes almost all latency, and dominates all mechanical drives in random performance, this is a large chunk of what people actually do, so it has a large perceived improvement from an end user.

-----

Right, but you're leaving out the problem I noted earlier beyond the price of SSDs, that being that there is a limited number of writes they can perform and system drives tend to have a lot of writes going on. Thus a system drive will wear out sooner if an SSD is used compared to a HDD. The average life expectancy of an SSD configured as a system drive is roughly two years from literature I've read.

Again, I mentioned this, you seem to glossed over major points in my post. I'll explain in more detail. SSD will track where writes are heavy and when they get more usage in one area of the SSD, it puts some block of data there that doesn't get written much and does the heavy writing somewhere else. If you're reading about average lifespans of 2 years from modern SSD drives, you're reading either outdated literature or someplace other than the places I'm reading:
http://www.storagesearch.com/ssdmyths-endurance.html
http://communities.intel.com/message/68106

Intel also claims to has solved (or at least greatly improved) the write cycle life span by reducing the 16 to 32 I/O operations required for each erase and write cycle in current SSD's down to 1.1 I/O operation per erase and write cycle. This alone would increase the life cycle of the SSD significantly and Intel claims that the wear-leveling performance over previous generation SSDs to be a full factor of 3 greater.

Estimates are on the order of 10-15 years unless you re-write your drive every few minutes. The future is today. SSD is a reality. This coming from someone who works manufacturing media for mechanical drives. Large scale adoption of SSD drives puts me out of a job. They are feasible today for the people who would be willing to shell out for a SAS drive.

Also, if you're looking for reliability, mirroring is not the way to go. If you want the absolute best reliability, ie better than 99.9999999% uptime, you go with Raid 6+5 (Raid 6 is relatively new using 2 parity disks meaning you must have a minimum of 4 disks to do it).

I don't want the absolute best reliability. I want "good enough" while being practical and usable. Again, the initial point I was making was designing a storage system better than SAS for cheaper.
Anything RAID 5 is impractical due to controller requirements. Parity bit calculations require real hardware controllers to have any reasonable write performance, which = big $$$, definitely more expensive than a basic SAS controller.
The other problem with RAID 5 is the issues that if your controller dies, you data is gone until you buy another controller. I used to use RAID 5. It works, but for home use it's not very practical, the controller becomes a factor in your reliability calculation, combined with the costs, it is not a practical solution for someone who is dedicating less than $1k to their storage system.

Mirroring is much more practical. A drive dies, and you have all your info on another identical, bootable drive with no special controller requirements, no special anything. When upgrading all your new motherboard needs is a SATA port, since there are plenty of ways to do mirroring without RAID. This is what I do now. The reliability of the system with 2 drives is already approaching cosmic coincidence level of probability, you don't really need more than that.

The other issue with reliability is that no matter how reliable your array is, there is a real threat of natural catastrophe (earthquake, hurricane, flooding, fire, etc..) This is where the 3rd drive in a firesafe or off-site comes in. Reliability of 2 drives is enough. Then add the third for the catastrophes.


Again, the point I was making was SCSI (SAS) in home usage. There are 2 main advantages to SAS: reliability and performance. My example was one that would outperform SAS in both areas while at the same time being cheaper. The points you bring are RAID 5 + 6? a 12 drive setup beats SAS in both areas and is cheaper? I'm not sure that in real world performance it actually is going to beat a 15k RPM SAS drive in performance, for one. It definitely won't beat it on cost for 2, a 12 port RAID 5/6 card that doesn't stuff write performance is probably around the same cost of 600 GB of SAS drives.