>>
>>It's true that DB apps make more extensive use of disk I/O than Word, for example. My point was that write caching is an OS-level service, operating "below the horizon" of applications. Apps can't choose to use or not use write caching - if it's on, they all get it, if it's off, they don't.
>
>Not true. Go buy a Compaq Proliant Server with a disk array. The drive controller has an onboard hardware cache that is NOT controlled by the OS. In fact, you have to down the server and run Compaq setup tools to turn off the cache. This caching has absolutely nothing to do with the OS and works the same whether you are running NT, Netware, or Unix.
>
The only part of my paragraph not strictly true was the "OS-level" reference. You're right, the controller (whether Compaq, Mylex, Adaptec etc.) can effectively work at the hardware level. However, this merely reinforces my point, which is that applications can't choose whether they want to use write caching or not.

>>
>>The harder any app pounds on the disk subsystem, the more important write caching becomes. File-based databases are by *NO* means the only apps capable of saturating a disk. If there's a problem with write caching with a given controller, it will become apparent just as rapidly with SQL Server or any other type of DBMS.
>
>SQL Server uses different algorithms to update files. While the problems can happen, they aren't as visible.

It does not matter what type of algorithm is generating disk writes. As far as the disk subsystem is concerned, it's asked to write information to sectors and tracks. Also, I fail to see how corrupted SQL Server data is any less serious than corrupted VFP data.
>
>>
>>Disabling write behind caching in modern OSs is very much a case of throwing out the baby with the bathwater.
>
>I have seen cases of index/file corruption disappear when turning off the write cache. It very much can be a problem with file-based systems like VFP.

As I've said before, if it's a problem with file-based DBs like VFP, it's a problem for the entire system and all its apps, period.

If you've actually made problems disappear by disabling a write cache, then you've fixed a symptom, not the problem. A better solution would have been a firmware update to the drive controller and/or OS disk driver update (if applicable).

Fact is, as CPU speeds increase, so does the disparity between silicon and disk performance, and the importance of write-behind disk caching.