>>Write caching is a technology that's been around for a long time. It's well understood and has been reliably implemented in thousands of different configurations. Turning it off can result in a large performance hit and should never be undertaken lightly.<
>
>It's not "write caching" that is the problem per se; it's the "I/O complete" notification.
>
>Apparently, there were/are some controllers that would notify the O/S that "I/O is complete", when in fact it wasn't; they would post the notification and then do the writing ("write-behind", I think it's called). A problem could arise now if the controller (or something) crashed and there was no battery backup; the "system" assumes the data was written, when in fact it wasn't and there is no way to recover. Or ... one could "reset" the controller, which would dump the cach, possibly AFTER a notification was sent but before the write.
>
>In any event, turning of write-caching (with SQL Server) "might" not make a "big" difference (5% at 250 I/O per sec).
>
>One controller that supposedly can handle the above issues is the "Compaq SMART-2" (whatever that is).

I think we may be arguing semantics here. I'm using "write cache" and "write behind" interchangeably. The purpose of this technique is precisely to post a notification back to the OS when in fact it has not been committed to disk. By decoupling, the controller can use advanced techniques to increase effective throughput and decrease the number of actual, physical writes the system has to perform. In order to do that reliably, the controller has to maintain cache coherency, which is non-trivial but is well understood.

You're absolutely right that such controllers must be backed up by UPSs, or data loss may result on loss of power. This holds true of desktops/workstations that employ this technique, as well as servers.

People think nothing of using multi-CPU Xeon servers with multi-level processor caches up to 2MB in size. Conceptually, a properly implemented read-and-write disk cache is exactly the same thing and operates just as transparently. We don't get warnings from Intel or AMD to disable CPU caches if database applications are run on them; there is no reason to do so on a caching disk subsystem, either.