BTW this is a nice example of what happens with read performance - even with TRIM:
You can easily spot static from dynamic data here; the remapped/fragmented portions have a dip while static data has a horizontal line.
Yes, but no random read performance increase; i did manage to get ~1250MB/s with 5 Intel X25-V 40GB in RAID0; that means 250MB/s per drive; close to 100% performance scaling with RAID0.
So it could be that RAID0 random I/O performance gains are only apparent on BSD/Linux systems, not on the Intel RAID0 drivers.
I would be interested in seeing such benchmarks though; but often the benchmarks are either not done properly or show low performance. Its a shame; Windows just doesn't like RAID.
*
My post in a different forum regarding the same but using two 80 GB Intel drives. Many commentators note that losing TRIM is not such a bad thing with the Intel controllers (and the same could be true for other SSD controllers). Basically, the newer controllers are much better at recycling sectors even in RAID and even without TRIM.
I would point to the erase block fragmentation issue on Intel SSDs, and is still under investigation by Intel.
* Lastly, there are some comments in this thread that are controversial. I'm not an expert and I'm not saying they're wrong, just that I believe there is disagreement among the experts on these remarks and you should be aware of it:
That is true, but really in Windows-world there are alot of assumptions are just aren't true. Or they have been true for other reasons than people think.
I should note that the claims i make are perfectly valid for ME, as i've tested my Intel X25-V 40GB battery of 5 SSDs in combination with FreeBSD+ZFS; and of course also done benchmarks on this array. I also have decent experience benchmarking RAIDs; and generally feel to have a deeper understanding of how performance works and which numbers are important and which are not.
I do agree some statements are controversial. But the controversy would be about FreeBSD RAID0 performance being irrelevant to Windows users who want RAID0. That is certainly true. Just know that RAID0 *CAN* scale properly in random IOps; but that at least some Windows drivers do not actually deliver this performance potential.
My potentially flawed understanding is that in THEORY, smaller stripe sizes are better. This is because striping is where you get your speed increase from RAID -- you WANT your data to be spread across both drives so that when it's read, both drives kick in. With a large stripe size, small files can end up being located on only one drive instead of both. So if you are working a lot with 10mb files, and have a 128k stripe size, you are going to get a significant performance boost from RAID. But if you work with many small files, say 10k, 20k, 100k files, then with a 128k stripe size, you may get a very weak performance boost, because these files are smaller than your stripe size.
You think well, i like that.
Let me help you:
In your example, with 128k stripe and say 8k files, you say that when reading one file, it is only stored on one HDD and thus only one HDD will be accessed when reading this file. TRUE!
BUT - that also means the other three HDDs in the RAID0 array are entirely free and can handle other requests if they are available. For this to work, you need a higher queue depth than just 1. I'll talk about queue depth later. But assume alot of requests are waiting, now look what will happen:
HDD1: seek to file 1, read file 1
HDD2: seek to file 567, read file 567
HDD3: seek to file 890, read file 890
HDD4: seek to file 234, read file 234
Now thats one seek+ 8k read for each HDD, assuming seek time is 11,1ms (5400rpm) and transfer time to read the 8KiB is (8 / (100MB/s * 1000) * 1000 = 0,08ms.
Total time: 11,1 + 0,08 = ~11,2 ms ( = 357 IOps, calculated with: (1000 / 11,2) * 4 = IOps)
Now look at how a single drive would do this:
HDD1: seek to file1, read file 1, seek to file567, read file 567, seek to file 890, read file 890, seek to file 234, read file 234
That's's 4 seeks and 4x8k read. seek times will account for (4*11,1) 44,4ms and the transfer time will be (4*0,08ms) 0,24ms.
Total time: 44,4ms + 0,24ms = ~44,64 ms ( = 89,6 IOps; close to 25% that of 4-disk RAID0 array)
Now look how a 4-disk RAID0 array with 2KiB stripesize would do this:
HDD1: seek to file1, read portion A of file 1, seek to file 567, read portion A of file 567, and the other two as well
HDD2: seek to file1, read portion B of file 1, seek to file 567, read portion B of file 567, etc
HDD3: seek to file1, read portion C of file 1, seek to file 567, read portion C of file 567, etc
HDD4: seek to file1, read portion D of file 1, seek to file 567, read portion D of file 567, etc
Each portion would be 2Kilobytes; so 2 * 4 = 8KiB which is the size of all files in our example. So when reading each file, all HDDs are used. However, this also means they have to seek to each file. Each HDD handles 4 seeks and reads 2k four times. That means 44,4ms for seeks, and (4*0,02ms) = 0,08ms.
Total time: 44,4ms + 0,08ms = ~44,5ms ( = 89,9 IOps)
As you can see, the performance of RAID0 with small stripesize is very bad in this example. That is because you force all the disks to seek to the same file, they all seek to file 1, read a tiny portion of it, then all seek to the next file. That is not efficient as seek times are WAY higher than transfer time; the time to ACTUALLY read data is very short compared to the time it takes to seek to the file.
So the idea of having a large stripesize is that each I/O done (generally not larger than 128KiB) will be handled by one disk alone, so the other disks are available to handle other requests if they are available.
If those are not available, you would get near single-disk performance. Whether multiple requests are available depends on what applications you use. When reading large files from your filesystem, the filesystem will use read-ahead and read 8 blocks at a time, allowing multiple disks to be supplied with work to do.
The tricky part is called blocking I/O or synchronous I/O. If the pattern is random (non-predictable), only one disk in the RAID can do work with a higher stripesize. So things like booting, application launch and some applications do not scale with RAID0 at all; as they do unpredictable I/O where only 1 request is done at a time. So only one disk at a time is at work, with the others idling due to no other requests available.
You can compare this with multicore CPUs. Some applications only use one core, some use multiple. In either case, having two applications at work will also allow 2 CPUs to work even though the applications can only use one CPU. The same is true for RAID with a high stripesize.
That's THEORY. Practical considerations though are different. People think that with SSDs, the controllers react differently to different stripe sizes, and for each controller there may be an optimal stripe size (or range of stripe sizes) that the controller will handle best. For example, people have suggested that with the Intel controller, a stripe size of 16kb - 64kb is better. You should research your controller.
Its certainly true that RAID0 offers theoretical - potential - performance, but individual RAID
implementations (actual drivers/firmware that implements RAID) determines how much of this potential is actually achieved.
In addition, there's a lot of debate over whether using smaller stripe sizes risks excessive wear on your drive. The argument here is "yes, smaller stripes would theoretically improve performance, but they also mean a lot more write activity, and this is going to burn out your drives much faster.
I disagree on this argument. HDDs are particularly sensitive to heat variations (contraction/expansion of the metal) and to vibrations/physical shock. The seeking of your HDDs would not directly translate in lower lifespan. Likely, the HDD will die of something else first.