>(An oldie, I know, but I'm trying to catch up on replies)
>
>>Well, the "Users online" button did show you as being tuned in!
>
>You wouldn't be the first to ask if I ever log out. I've got DSL at home, and good bandwidth at work. Fact is, I probably just forgot to close the browser.
>
>>Thanks for getting back to me on this. I'm sure you'll post a report when there is more to say.
>
>Yes, let it be known now that I'll post something when I find out more. Though I can't say anything about how we'd deploy a fix (if any; just covering myself here) in the product itself, I'm currently researching how to flip whatever bit is necessary to turn off the write caching. I mean, what is it that unchecking the checkbox does? It's got to make some kind of call to the OS, since Windows 2000's HAL isn't going to let you diddle with that directly. So far, RegMon hasn't turned up much, and the MSDN is no help. Time to call in a few markers with my buds over on the Windows 2000 team, I think. <g>

I can tell you where the problem lies at this point - it's the ATAPI driver, which appears to reset the write cache status based on the system requerying the disk interface. I've not had this problem with any of the SCSI or FireWire drivers that I've used, primarily Adaptec product, but the hardware RAID adapters used by HP and Compaq, and the QLogic Fiber Channel HA all behave as expected. I've only seen this behavior with ATAPI drives, and the behavior seems to show up with the high-performance EIDE interface (UDMA-66 and UDMA-100 drives) using the MS-provided busmastering drivers, compatible with most Intel and NS controllers that support DMA busmastering at Mode 4 or better. I went ahead and proved out the behavior at least for the 440BX and 440GX chipsets using the Intel 82371 PCI busmastering interface chip; if I disable the on-board IDE interfaces and use an old ISA IDE adapter that supports through Mode 2, I don't see the behavior; it may be that the older IDE interface doesn't report something that's sent on more capable interfaces, and the performance is truly abysmal. I've gone ahead and replaced the one IDE drive I had on a Win2K box with a nice, fast 10KRPM Ultra-2 SCSI drive (I picked up a couple of 18GB Cheetahs from CSC for about $200 each; it's more than the new UDMA-100 EIDE drives, but it's a 10KRPM Ultra-2 LVD drive with <6ms access time, and since my Win2K boxes all have Adaptec UW or UW-2 HAs in them anyway, they blow the socks off even the newest EIDE drives...)

I've proven out the Adaptec 78xx/79xx family drivers, the RAIDPort II and III driver, the A133 driver, the QLogic FC family driver, and the Adaptec 1394 motherboard chipset driver as being well-behaved wrt the write-cache status setting, and proven out that the Intel 82371 and 82443BX chipset drivers exhibiting the behavior with UDMA-66 and UDMA-100 interface drives from Maxtor and Western Digital. The SCSI drives I've tested have covered the whole spectrum of SCSI-2 or better interfaces, anything from some older 2GB Conner SCA drives, several Quantum family drives, the Cheetahs I just mentioned, and the IBM UltraStars; I've used Seagates on both Fiber Channel and FireWire. My guess is that EIDE, not supporting TCQ, disconnect/reconnect or multiple commands queued to single targets, delivers poor performances without deferred writes from the OS to help manage the channel, and the driver enables the caching behavior to improve performance whenever the channel re-negotiates the channel protocols. THis is guesswork; I didn't delve into the innards of the OS with a heavy-duty debugger; it's based on observed behavior with a broad range of test environments.