I'm also a bit concerned with the way that the tool initializes its test file, as it seems to create it very quickly. The stripe size on the array is 256 kilobytes, so my theory is that the tool doesn't appropriately generate random numbers which access all the drives in the broadly-striped array. (It's easy to verify this happens by copying a file to the array-all drives are pretty equally active.) I would have expected the accesses to be spread across all drives in the array, making all the lights flicker.
When running the test, I only saw five disk drive lights in the array flickering. However, when doing so, I was surprised to find that the access pattern of the test seems to be off. I was able to reproduce the poor performance of this setup using a different machine with a similarly configured array. That rig is a Core i7 945 box running Windows Vista 64 with a EVGA SLI motherboard and 12 gigs of memory, and the drive attached to a SATA port on the motherboard. I also ran the program against an Intel X-25E 64 gig drive on my desktop machine. This means that the driver must still do some buffering, which enables it to do caching, which will alter the results. One of the most important is that the program uses FILE_FLAG_NO_BUFFERING when creating the file handle that it reads to or writes from, but does not provide an aligned buffer to the ReadFile() or WriteFile() calls subsequently used against the handle. I spent some time reviewing the source code, and found some interesting anomolies.
0 kommentar(er)
