Write cache buffer flushing.. Too dangerous to disable?

[Carfax83]

Just curious, but how many people have write cache buffer flushing disabled on their PC?

Windows advises you to only disable it if you have a UPS in case of a system power loss. I've enabled it before many times, and I found that it really does help increase I/O performance, particularly for RAID arrays. Disabling it on my computer results in reduced boot time, faster application loading, more responsive OS. Basically, anything that's I/O limited will receive a performance increase.

However, I've found that disabling it can be very dangerous. Last year, I had corrupted system files on my Windows 8 installation (TWICE it happened to me) that was completely unrepairable, which I'm 100% certain was due to disabling write cache buffer flushing.

Even though I have a UPS which gives me about 20 minutes of auxiliary power, which is more than enough to shut the computer down properly in case of a power loss, I still got corrupt files when I had to do a forced reboot due to freezing or crashing because of unstable overclocks.

However, I never had this problem when I was on Windows 7 though, and I always had write cache buffer flushing disabled, which leads me to believe the setting may have been buggy on Windows 8. Now that I am on Windows 8.1, I'm tempted to try it out again as my system is now more or less, completely stable.

So what are your thoughts, and do you have the setting enabled or disabled?

For those that don't know about this setting, you can check to see if it's enabled or disabled by going to device manger, and clicking on disk drive, right clicking on your volume disk, then properties, and then policies.

 

[Cerb]

No. No. And...no. I've seen the results of LVM not respecting barriers in Linux, on plain COTS boxes. As an opt in feature, no no no no no no no...

It's not a matter of different versions of Windows, but what was or wasn't written at the time the drive stopped getting data, and/or lost power (version X may be writing more often on your PC, causing more chances for corruption, though). If you don't do much IO-heavy work, Windows will still write data out to the disk, so during no/low IO periods, there won't be a difference. But, NTFS is not a log-structure FS, so having barriers properly implemented is important to data integrity. Partial writes with writes in an unexpected order are not going to be the easiest things to recover from.

Also, SSDs are quite affordable, these days.

 

[ashetos]

No. No. And...no. I've seen the results of LVM not respecting barriers in Linux, on plain COTS boxes. As an opt in feature, no no no no no no no...

It's not a matter of different versions of Windows, but what was or wasn't written at the time the drive stopped getting data, and/or lost power (version X may be writing more often on your PC, causing more chances for corruption, though). If you don't do much IO-heavy work, Windows will still write data out to the disk, so during no/low IO periods, there won't be a difference. But, NTFS is not a log-structure FS, so having barriers properly implemented is important to data integrity. Partial writes with writes in an unexpected order are not going to be the easiest things to recover from.

Also, SSDs are quite affordable, these days.

This. Wanted to add that a UPS does not protect you from a random crash (e.g. buggy driver). Imagine an OS crash causing file-system corruption.

 

[corkyg]

I have write cache disabled for an external backup data drive for the purpose of on and off without having to go through the remove hardware gate. It works perfectly for me, and has done so for the past 6 years. The poll question and choices do not provide for a response in my situation.

Except for that drive, write cache stays fully enabled on all internal drives.

 

[Cerb]

I have write cache disabled for an external backup data drive for the purpose of on and off without having to go through the remove hardware gate. It works perfectly for me, and has done so for the past 6 years. The poll question and choices do not provide for a response in my situation.

That's a different setting. In the dialog where you set that, if you have caching enabled, the option to disable buffer flushing is below it, and off by default. I also turn write caching on for drives I use regularly, as the speedup is substantial on USB 2.0.

In a non-journaled file system, the update to the data and metadata need to occur simultaneously. Of course they can't, so a barrier is used to hep make sure that the changes are all done before it goes on to other writes. If a new write occurs to a file, but its metadata isn't updated, you have corruption. Likewise, the reverse. Writes don't have to have strict ordering, but metadata and data need to be synchronized. What buffer flushing does is tell the drive to write out all its data, because we know that, except for most SSDs, drives lie, and actually do write caching, even if you tell them not to (this is part of why SSD makers have often made it a big deal that they buffer, but not cache, writes).

In a journaled file system, the same thing is still true, except that it understands that the linked file contents and its metadata don't ever reach the platter at the same time, and shouldn't be expected to. What if the journal is cleared, or a recent write marked as completed, but some of the file data or metadata haven't made it to the platter yet? You have a situation where corruption occurred because new data got written before data that should have come before it. With just one file's data, this is simple and easy. But let's say there are 5 files in the middle of being written, and their current status is stored to the disk in different orders and amounts, per file. You want to do that when possible for performance, and let NCQ/TCQ work its magic, but every so many of them, the FS driver is going to want to stop and make sure it all got put correctly on the disk.

So the process is a cycle of:
1. Assume good state.
2. Write stuff in whatever order the disk controller, or the disk itself, thinks is best, for optimal performance.
3. Decide that now would be a good time to finalize those writes, matching together all the data and metadata.
4. Write out the final metadata, and that the file system is in a clean transactional state (an assumption, w/o a journal or log file system), and change the in-memory file system state to match.
5. Repeat.

Somewhere between starting 3 and completing 4, buffer flushing should be going on. As long as it gets done properly before going back to 1, anything that screwed up between 1 and 4 can be recovered from, as all of the writes after 1 can be assumed to be bad, and only allowed to stay if they can be verified as good, while all writes before 1 can be assumed to have eben correct.

 

[corkyg]

Thanks, Cerb. That clarifies the question. 90% of the time, that external drive (eSATA) is OFF.

 

[Mark R]

It is unfortunate that MS still have this option in Windows, and that they call it what they do.

It is of *NO* benefit to modern software. All this option does is to re-activate a bug from Windows 3.11, where Windows would sometimes ignore a request from an application to flush the write buffer.

MS re-engineered the disk subsystem for windows 3.11 and promoted it heavily to developers. Several vendors of accountancy software which used the "flush" command frequently to ensure data was guaranteed saved to disk, noticed that suddenly "flush" was much faster. So they used it a lot. One major accountancy software vendor used it every mouse click or key press. In reality, a bug in Windows meant that the data was not actually getting saved and was at risk of corruption (but no one noticed).

By the time Win 95 was in development, MS had noticed this critical bug and fixed it in Win95.

It didn't take long after Win95 launched for the accountancy software vendors to realise that on Win95, their software ran like a slug in liquid nitrogen. Pretty soon, MS was in court facing anti-trust suits from the accountancy vendors, accusing MS of deliberately breaking their software, to force customers to buy MS's offering, or from an MS-favored vendor.

The result was that MS added an option in Win 95 to re-enable "bug mode" - it was called "advanced performance" at that time, to keep the lawyers happy.

It's still there, but now called "disable write buffer flushing" (a more useful description), presumably to keep the lawyers happy.

The point is that this option doesn't change the normal disk caching behavior, and it doesn't affect file system write barriers. All it changes is the behavior when an application wants explicitly to flush it's file buffers (to check that critical data has been saved). The normal background buffer flushing that the OS does is not affected.

In summary, this option is ONLY useful if you are running ancient, buggy software from a vendor that sued microsoft because they couldn't believe that their software depended on a bug in OS to work properly.

 

[readymix]

Interesting. This feature crossed my radar yesterday when I was messing with the Samsung magician. I found my 840pro benchmark writes were in a cliff dive and it turns out it was related to the intel rste drivers. with WCBF disabled and rste installed, the 840pro performed as expected. with msft or rst drivers and WCBF enabled it also performed as expected. Conclusion; WTF.

 

[Cerb]

The point is that this option doesn't change the normal disk caching behavior, and it doesn't affect file system write barriers. All it changes is the behavior when an application wants explicitly to flush it's file buffers (to check that critical data has been saved). The normal background buffer flushing that the OS does is not affected.

In summary, this option is ONLY useful if you are running ancient, buggy software from a vendor that sued microsoft because they couldn't believe that their software depended on a bug in OS to work properly.

Hmm, and here I was thinking it did what it said it did. Would it have also, "helped," Firefox, before they were forced to deal with the fsync bugs, instead of blaming OSes? Seems like it would still be "useful" to other programs, and could allow the OP's RAID to be faster, since programs that want to store file data like to sync.

http://www.tomshardware.com/reviews/ssd-performance-tweak,2911-15.html
unexpected

 

[Carfax83]

OK here's an update. I couldn't help myself and decided to really test out the setting.

I disabled write cache buffer flushing, and enabled write back cache (this only becomes an option when the former is disabled) and I could definitely feel a performance improvement.

It's slight though, so it doesn't really merit the dangers and in the end, I decided to turn it back off.

However, I have a question for Cerb or anyone informative. During my testing, I was playing AC IV and I had a BSOD; clock watchdog timeout.

Luckily there was NO DATA LOSS, but I was very surprised, as this indicates that one of the cores on my CPU isn't getting enough voltage. I had stress tested my computer fairly rigorously and I hadn't had that BSOD for a long time.

Anyway, I went back into the BIOS, increased the voltage a notch, and played AC IV again to see if it would BSOD; and sure enough it did at the same spot as well, this time with a WHEA hardware event error.

Now I was really perplexed. Something was causing my machine to become unstable, but since I had played hours of AC IV just a few days ago, I couldn't imagine what it was that was causing it.

The only thing I had changed was the write cache buffer flushing and write back cache settings, but since those affected I/O performance, I didn't see how they could effect my CPU.

Anyway, I disabled them on a hunch and replayed the same segment of AC IV twice in a row.

NO CRASH or BSOD

And this is what I want to know. Does disabling the write cache buffer flushing and enabling write back cache cause the CPU to work harder or something?

Another factor was that I recently updated my RST to 12.9, the latest version. Not sure if that could have done it.

 

[Carfax83]

Also, SSDs are quite affordable, these days.

I'm seriously eye balling the Samsung 840 Evo 1tb. Just waiting for it to drop a little bit more in price and I'm pouncing on it!

 

[Mark R]

Hmm, and here I was thinking it did what it said it did. Would it have also, "helped," Firefox, before they were forced to deal with the fsync bugs, instead of blaming OSes?
http://www.tomshardware.com/reviews/ssd-performance-tweak,2911-15.html
unexpected

Well, it can't actually do what it says it does, because write buffers have to flush at some point, not least when they become full.

This option should make an app that calls fsync a lot faster, by effectively rendering fsync into a NOP. If firefox was running into problems with fsync, then I suppose it would "help".

The SSD benchmarks are interesting. My guess is that the benchmark program calls fsync periodically, in order to defeat write caching and ensure an accurate measure. However, with fsync disabled, the data piles up in the OS's write cache and then gets flushed to disk as a series of random writes, in such a way that the SSD finds them difficult to manage.

 

[readymix]

From the RST help docs.


By default, Windows* write-cache buffer flushing is enabled to ensure data integrity. This means that the system will periodically instruct the storage driver to write all cached data to the main storage media. These periodic commands result in decreased overall system performance.


You can choose to disable Windows write-cache buffer flushing to restore system performance, allowing the Intel® Rapid Storage Technology driver to handle all write-cache buffer flushing.

 

[kzinti1]

Why did this thread suddenly end with no definite answer?
I have quite a few Samsung SSD's and this option is in the Magician software.
Do I enable Write-Cache Buffer Flushing or not?

 

[Carfax83]

Why did this thread suddenly end with no definite answer?
I have quite a few Samsung SSD's and this option is in the Magician software.
Do I enable Write-Cache Buffer Flushing or not?

Write cache buffer flushing is enabled by default. The question is, is it safe to turn off..

The general way of thinking is that WCBF is not safe to turn off have if you're on a HDD. When I made this thread, I was using 600GB Raptors in RAID 0.

But for SSDs, WCBF shouldn't be an issue, because SSDs can flush the data much faster than HDDs can in case there's a freeze or BSOD or something and you need to reset.

But if you have a power outage, that's another matter entirely. It's conceivable that you could experience data loss.

I bought a Samsung 840 Evo 1TB and I've had WCBF disabled but I'm on a UPS backup, so if I do experience a power outage, I can at least turn my computer off properly.

 

[BrightCandle]

As a programmer when I flush the write buffer I really mean it, its important that this happen when I tell it to for the proper functioning of my software. Its not just basic data integrity its also that the software and its critical sections needs the write to have been done before the critical section is left. Disabling this would make some of the software I have written in the past misbehave and crash in strange ways. Its not a good idea to disable this ever as I can't be the only developer that writes software with multiple threads where a lock is used to ensure the sanity of the system when writing and reading files concurrently, infact I know I am not.