Hi Folks,
Just another update for you. I believe I have exactly isolated the problem and I don't think it's related to RAID set, spindle count, etc. FYI we have done all tests on RAID 0,1,5 wit the same problem.
To explain in detail it appears that prior to Windows 2000 SP3 (i.e. RTM, SP0 and SP1) the MS code had a bug that allowed file data to be held in a controller write cache (with or without battery backed write cache or BBWC). This became a problem when power failed and you didn't have battery backed controller cache as you lost data. To resolve the data loss issue in SP3 MS fixed the bug by updating the disk.sys driver to send the SCSI command WRITE + FLUSH for every file write command. This SCSI command has the effect or forcing the controller to write its cache immediately to disk, thus bypassing any write caching that might go on - even if you've BBWC. As a result you get really poor write performance as you are writing directly to the disks bypassing the write cache. The read cache is always enabled as no data can be lost in a disk read.
The net effect of this is that a read from the MSA will have high-throughput (as it's from the cache) whereas the write will have poor throughput. Tesing with IOMETER will prove the read performance as you can do a pure read and IOMETER can be forced to filter the FLUSH command from the SCSI sequence to demonstrate high write throughput. The problem with IOMETER in this instance though it that it does not function the way Windows I/O happens (e.g. using Explorer, Exchange, SQL, etc). Therefore it can give inaccurate results at to the overall true system performance.
Microsoft posted a SP3 patch that was included in SP4 to resolve this issue and enable write caching using dskcache.exe. The problem is that either the MS or HP driver ignores the WRITE command and automatically adds a FLUSH command. By placing in a FLUSH command filter (using a small kernel mode drive) the high write throughput can be obtained. However this is not a supported by either MS or HP configuration.
Upon escalation of the issue to both vendors (MS + HP) each is adamant that it's the other vendors issue. To be fair to MS at least they are still troubleshooting it, HP are of the opinion it's purely a MS issue - and maybe they are right.
This problem was resolved using Windows 2003 and the "Enable Advanced Performance" option. Which effectivley filters out the FLUSH command but in an MS approve code base (i.e. you have support).
Checking of LUNS, RAID sizes, types, etc. I don't believe will resolve the issue. It simply a software issue with Windows 2000 SP3 and SP4.
I hope this clarifies for everyone.
Cheers,
Jason.
