Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a Windows Server 2008 x64 Standard virtual machine that runs on a machine with a hardware RAID controller, a Perc 6/i, which has a battery on-board.

Doing everything I can for additional performance, I think I should disable this. Is this very dangerous though?

My understand is that Battery Backed Write Caching gives a performance boost to the host OS, telling it the write was complete when they are still sitting in flash waiting to be written.

However, I can't see how it would be detrimental to performance, but is there a gain (even if marginal) to enabling it / disabling it?

P.s. There machine has a backup power.

Here is a screen shot for clarification:

screenshot

share|improve this question
    
+1 for hosting the screenshot with a provider that displays pictures of girls –  Brent Pabst Sep 5 '12 at 15:24
    
And musculus guys, if you're into that –  jwbensley Sep 5 '12 at 15:25
add comment

2 Answers

Whenever a Windows application is writing data to disk, this data is written to the host memory first.

A "normal" write request returns immediately after the data is in memory and a queue entry indicating that this data needs flushing to persistent storage is created. A mechanism called the Lazy Writer ensures that this queue is being processed periodically (1/8th of the queue is flushed by the lazy writer every second by default). This is the mechanism you are disabling by unchecking "enable write caching on the disk" - every write request would need to wait until it has been acknowledged as "written" by the storage device before it returns.

Applications with specific requirements for data integrity (databases, filesystem drivers) do have options for a more intelligent approach to caching. For writes which need immediate persistence (NTFS journal, database transaction logs) FILE_FLAG_WRITE_THROUGH can be specified with the write. In this case, the write call would not return before the data is actually committed to persistent storage. Unless you activate the "Enable advanced performance" checkbox which causes the cache manager to ignore FILE_FLAG_WRITE_THROUGH, return the call immediately and pass it to the lazy writer as every other "normal" write.

As you have two additional layers of caching1 (numer one is your host operating system running the KVM hypervisor, number two is your storage controller with a BBWC/FBWC), things are getting more complicated. Each of these layers would provide you with similar choices and as every write request has to pass through all of them, the weakest link of the chain will be effective to your data's integrity.

Application developers at large do know and understand the effects of caching and write through calls. So really critical data parts are written with FILE_FLAG_WRITE_THROUGH while everything not written with this flag can be considered as safe to be cached in volatile memory. The trouble starts when FILE_FLAG_WRITE_THROUGH is being ignored at any layer and the data is actually lost in the case of a power outage or a software failure. Such conditions usually result in corruptions in filesystems and transaction logs, leading to unpredictable results and maybe even requiring you to restore from a backup, so this obviously should be avoided. If your storage controller's cache is "battery-backed" or "flash-backed", it can be considered "non-volatile" to a certain degree, so it generally is considered safe to use its write-back cache even for write-through requests2.

The bottom line: it generally is safe to "Enable write caching on disk" unless you are dealing with broken applications which are not using FILE_FLAG_WRITE_THROUGH but need every write to be persistent. Disabling this would not hurt too much in your case as most calls should be handled by the storage controller's write cache and return nearly immediately (but you likely would have additional overhead from this though and the cache size would be limited by the controller's DRAM). You never should "Enable advanced performance" or "Turn off Windows write-cache buffer flushing on the device" on a system where you value uptime or require data integrity.

Further reading:

MSDN Libary - Windows File Caching
Smallvoid blog - description of the hard disk cache


1 actually there even is another layer of caching at the hard disk itself, but in most cases the write through request is honored no matter what the drive's cache settings are. Some flash drives are notable (read: broken) exceptions to this rule though - with flash SSDs, writes are usually cached and reported as written immediately but only committed to volatile cache - not just for performance reasons but also to coalesce writes and prolong the life time of the flash cells. The "enterprise" versions of flash SSDs usually have capacitors which would ensure the drive has enough power to flush the cache to flash cells, the "consumer" versions often don't - beware of those.

2 it obviously is not safe under all circumstances - if the battery is defective and it goes undetected, if there is a bug in the controller's logic handling the power failure case, if the power outage period exceeds the time the battery is able to provide power, if the supercaps or the flash cells of the FBWC go bust, data is going to be lost. But these occurrences are commonly rare enough to take the risk.

share|improve this answer
add comment

In general this is all correct. Essentially the data to be written is stored in memory somewhere near the physical disk, be it on the disk controller, the RAID controller or the storage device controllers. Heck it could even be on a caching card before being written to the actual physical disk.

The default is usually an acceptable solution as unless the server is a database server or other high-disk traffic service a power failure is unlikely to affect too much.

There are usually two things to consider:

  1. What does your disk/controller vendor recommend?
  2. If you trust your server's power supply the first checkbox is good. If you fully trust your disk's power supply the second checkbox is ok.

I have only ever used the second checkbox in an iSCSI setup with a dedicated SAN controller that had two on-board controllers as well as redundant power supplies all the way to the breaker. We were writing DB and VM data across the SAN so any loss of power was never a good thing.

share|improve this answer
    
Well this is a guest virtual machine as I have stated. I understand the points you are raising above. This server has dual power supplies fed by dual power feeds, with dual grid supplies (it's in a data centre). It is a 6 disk RAID 10 with a battery on the RAID card. I can't see how this relates to my VM guest though? It is running a database so I would assume the best idea here is to disable it (use the top most option) so that the guest is waiting for a write confirm from the host? Or do I have this back to front, and I should enable the bottom check box? –  jwbensley Sep 5 '12 at 15:59
    
With the VM your disk performance is still limited by the host. My guess is that leaving it on is going to be about the same as leaving it off as the hypervisor is going to return the "data written" response even though it may still be cached at the hypervisor level and then even the disk subsystem level. However, I can't seem to find any MSFT docs that say yes or no one way or the other. –  Brent Pabst Sep 5 '12 at 16:09
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.