What is the whole function and effect of "Turn off Windows write-cache buffer flushing on the device"

1. Your assertion in the first question is fiction. Windows API calls such as FlushFileBuffers() will still ensure that the data gets all the way out to the physical media, even with write buffer flushing disabled. So, programs that are "safe" and know what they're doing are going to be just fine. Calls such as FileStream.Flush() in .NET, etc. eventually call this API.

2. Programs that do a lot of disk I/O without calling FlushFileBuffers() directly, or any helper API that eventually calls it, would see the most noticeable performance increase. For instance, if you were running non-essential I/O where it's okay if data gets lost, such as BOINC (if it gets lost you just re-download the file or attempt to re-compute the calculations), you could avoid calling FlushFileBuffers(), and just call an API like WriteFile() -- the data will get buffered to be written, but it won't actually be written for potentially a long time, such as when the file descriptor is closed, or when the program exits. Unfortunately it is also possible that if the system crashes (such as a BSOD), all the data is lost, so it is really important that if you are dealing with any kind of valuable / non-replaceable data that you do do call FlushFileBuffers(), whether buffer flushing is enabled or not! Otherwise a simple driver bug (for instance in your graphics driver) could cause you to lose a lot of data.

3. Can't find any benchmarks, but you'll notice it more with programs that fit the description in the second item above.

4. Syncing data to disk isn't actually that fast, especially if it is done frequently in a tight loop. By default, if I recall correctly from reading Windows Internals books, NTFS by default syncs all dirty filesystem buffers to disk every 5 seconds. This is apparently a decent tradeoff between stability and performance. The problem with frequently syncing data is that it makes the hard drive do a lot of seeks and writes.

Consider the following pseudocode:

1: seek to a certain block (1)
2: write a couple megabytes of data into blocks starting at (1)
3: wait 2 seconds
4: seek to another block (2)
5: write some more megabytes of data into blocks starting at (2)
6: seek back to block (1)
7: write some more megabytes of data into blocks starting at (1)
8: wait 10 minutes
9: seek to block (1)
10: write some megabytes of data into blocks starting at (1)
11: wait 5 seconds
12: seek to block (2)
13: write some megabytes of data into blocks starting at (2)
14: explicit call to FlushFileBuffers()

With automatic 5 second buffer flushing on:

• The writes occurring on lines 2, 5 and 7 occur in RAM and the disk doesn't move, until 5 seconds have elapsed since the first write, and then the latest data (from line 7) gets written into block (1) and the only data written into block (2) gets written.
• The writes occurring on lines 10 and 13, which overwrite data in blocks (1) and (2), have to get written out to disk again
• So the total number of times that block (1) got written to RAM is 3, and to disk, 2. The total number of times that block (2) got written to RAM is 2, and to disk, 2.

With automatic 5 second buffer flushing off (the effect of the checkbox in your question):

• The writes occurring on lines 2, 5, 7, 10 and 13 occur in RAM and the disk doesn't move, until line 14 is executed, and then the latest data (from lines 10 and 13) gets written into blocks (1) and (2). The old data from lines 2, 5, and 7 never hits the hard disk!

Considering that a busy system can experience between hundreds to tens of thousands of writes to files per second, this is great for performance, especially on traditional spinning hard drives (it's less impressive on SSDs). RAM is 20 times faster than hard drives as a general measure, although that gap is less with SSDs.

The reason they say you should use a battery backup is that you don't want to have 35 minutes worth of written data buffered in RAM that isn't written to disk just because your programmer was lazy and didn't call FlushFileBuffers(), and then have a power failure. Of course, a battery backup doesn't protect you against driver bugs that cause a BSOD....