For example, if the access pattern was short sequential reads, where most of the IOs come out of the drive cache, then the IOPS rate can grow from 100 to close to 100,000! And in the case of the StorageReview numbers you mention above, the access pattern is probably some mix of sequential and random, short and long, read and write. Who knows.

As far as read and writing the 10GB file, it really depends on the transfer size. For example, does the OS access it 512 bytes at a time or 64KB at a time? That will make a HUGE difference in performance. There’s also the issue of fragmentation. Is the file spread across the disk making the IOs random, or is it located in one general region making the IOs sequential?

Performance is tough. It’s easy to characterize disk and controller performance using specific metrics, like long sequential reads, short random writes, etc., but matching those up to real world access patterns is very, very tough.

TT

Yes, I believe SQL’s chunk size is 8KB. And it looks like diskmon is confirming that. Even though the “length” field has no units, I’m 99% sure that it’s in blocks (512 bytes each) based on a quick test I ran on my laptop. The smallest number is 1 and the largest is 128, and I know that Windows does a lot of 512 byte and 64KB transfers, which would be 1 and 128 blocks, respectively.

So as long as your stripe size is a few multiples of 8KB you won’t be having many stripe crossings. For example, with a 16KB stripe size, you’d have 50% of the commands crossing a stripe and therefore using twice the disk IOs. 32KB would have 25% crossing, 64KB 12.5% crossing, etc. 128KB is a good default for RAID-10. Since you’re mostly running random IO you don’t have to worry about keeping the stripe size low enough to create long coalesced IO out of short sequential IO.

TT