Bits & Bytes: We have been experiencing problems with our Exchange 2000 servers connected to our SAN for over a year. At various times of day, either high utilization or low, we experience loss of connectivity to the SAN-attached disk. The following error is returned:dmio: Disk Harddisk1 block 39529167 (mountpoint F:): Uncorrectable write error dmio: Harddisk1 write error at block 39529167: status 0xc000009a The switch reports no errors and the HDS box reports no errors. Only Microsoft reports an issue. We upgraded all the code recently to the follow with no improvement.
The disk is HDS 9960 RAID5 code level: 01-19-26-00/00 The switch is Brocade 6400 2.6.1 The HBA is JNI (TROIKA) Zentai Firmare: 0x820000ae Driver: 220.127.116.11
This is a known error. According to a Microsoft knowledge base article number 329075, there are a number of possible causes. Since you seem to have been having the same issues with multiple storage devices from different vendors, the most probable cause are system or driver settings. The certified JNI Zentai driver for your array is number v18.104.22.168.27. The proper settings for your HBA came with the documentation. You should call your storage vendor to help assist you in making sure your HBA adapter settings and driver version are implemented properly. Microsoft lists the following as the probable cause, and the way to fix it. This problem occurs because of a combination of conditions or factors that include: 1. The computer uses the /3GB setting in the boot.ini file. This setting substantially reduces the total number of Page Table Entries (PTEs) that are available to the kernel. 2. The computer uses a storage adapter that can handle many simultaneous requests (up to 0xFF -- 255 decimal). 3. The storage adapter driver must map a buffer for each request that the SCSI miniport dispatches. When the SCSI miniport dispatches a high number of large requests, the system runs out of PTEs. 4. The storage stack on Windows 2000 does not guarantee forward progress under memory pressure. The failures occur after the following sequence: (Backup sends large I/O requests). An application sends the adapter a very large I/O request. The class driver splits up this request based on the maximum transfers the adapter can handle. For each piece of the request that the class driver sends to the port driver, the class driver sends an I/O request packet (IRP) by using the original MDL that represents the whole buffer. The port driver maps the whole buffer for each of these pieces. Because the adapter can handle many requests and also maps redundant copies of these large buffers, the system eventually runs out of PTE resources. The solution is to: 1. Remove the /3G parameter setting from the boot.ini file if used. 2. Edit the registry to reduce the concurrent I/O requests that are permitted by the mass storage controller. Use this link to find the article: By the way, I love those Zentai adapters, they provide the fastest and most transparent path failover I have ever seen. Hope this helps!
Editor's note: Do you agree with this expert's response? If you have more to share, post it in one of our .bphAaR2qhqA^0@/searchstorage>discussion forums.
Dig Deeper on Data storage strategy
Related Q&A from Christopher Poelker
SAN expert Chris Poelker discusses how to change the size of a LUN in a Microsoft cluster server environment. Continue Reading
SAN expert Chris Poelker compares connecting a SAN with wavelength cabling and dark fiber and discusses the pros and cons of each. Continue Reading
Storage expert Chris Poelker discusses SATA/SCSI compatibility issues in this expert advice article. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.