No, not just random IO, but parallel execution of requests. Rotational drives cannot pipeline the requests - they have to execute one request at a time. With SSDs you can send multiple requests (via NCQ), and they will be executed in parallel. The drives can literally satisfy multiple requests at the same time (at the moment, about four requests in practice, from my testing). That means that a single SSD drive is similar to having a striped RAID of four rotation drives, plus the benefit of no seek latency.
In anticipation of the likely "but it's not really parallel!" rebuttal, I'd like to point out that the internal parallelism is only important for its effect on throughput and latency. Parallelism is not a magic bullet.
Sure, but that's a hack - you can scavenge some data in some cases but you have no guarantees (or even high likelihood) of getting the stuff you want.
SSD parallelism is important for its effect on throughput and latency. If you're reading a database index to satisfy multiple queries, and you need to read in leaves from totally different disk locations you can do it in parallel in SSDs. This has huge potential to improve performance (once databases get around to taking advantage of this).
You pitch SSD parallelism as if it's a good thing, but another way to look at it is that you have to have I/O concurrency to get full performance out of some SSDs. Many common workloads have an I/O depth of 1 and thus won't get as much benefit from SSDs as people may expect.
Nah, a single drive won't saturate SATA (not in the situations I'm testing under, anyway), but a RAID of multiple drives might saturate SAS (not sure yet).
I don't know. We're testing one drive at a time for now, so we don't have very much information on bus saturation. I expect to move on to RAID controllers/Motherboard testing in a month or two.
Intel and Indilinx SSDs are saturating SATA today for sequential reads, but that's generally not why people use SSDs.
Ironically, many SAS controllers can handle fewer IOPS than an Intel ICH SATA controller; SAS 2.0 controllers are supposed to be better in this regard.
I've often wondered why spinning hard drives don't have multiple heads per platter. For example, two heads spaced out on the same arm could conceivably cut seek times in half. Or, a second arm on the opposite side could offer similar benefits.
The head-positioning firmware would get more complicated, yes, but for the fixed cost of getting those algorithms right many multiples of increase in seek times and transfer rates would be possible, by adding arms and heads.
Perhaps the competition from SSDs will trigger some new approaches in mechanical drives, as well.
I've wondered that too (mostly about extra arms). Then I wondered how much it would cost to add an extra arm versus the cost of the drive itself. Eventually I stopped wondering.
It's my impression that they stopped because of alignment issues, something like "it's hard to read something with one arm if it was written with a different one" and/or "it's hard to keep writes by different arms separate", not because of cost.
