Link to home
Start Free TrialLog in
Avatar of Craig_hannagan

asked on

Disable Write-caching policy within OS


I have a Dell PowerEdge R710 with a PERC H700 SAS Raid Controller. I have serveral volumes configured on this array and need to disable Write-caching within the Operating System (Server 2000R2) as this server is contantly writing important data to disk and needs to be in a consistent state if power is lost to the host. However when I try and change the Write-caching policy within Windows Disk Management I get a message stating "Windows could not change the write-caching setting for the device. Your device may not support this feature or changing the setting" I have attached the screenshots of the error and where I am trying to disable it.

I have Server 2008R2 installed on a PE 2950 with a perc/5i and it allows me to disable write cache in Windows and also keep write cache enabled on the raid controller, therefore we cannot see it being an OS limitation.

Does anyone know how disable write-caching within the OS without getting an error?



 User generated image User generated image User generated image User generated image User generated image
Avatar of PowerEdgeTech
Flag of United States of America image

This setting has no bearing on the cache of the individual drives.  If you have drives connected to a PERC, then the PERC disables the drive cache (or simply ignores it) in order to use its own onboard battery-backed cache.  You can change the controller's cache status in OpenManage Server Administrator.
Avatar of Craig_hannagan


Hi PowerEdgeTech,

Thanks for your response. The raid controller does have write-caching enabled at the moment and i want this enabled because it has battery backup and i need the performance.

So even though that write-cache option on the disk properties within windows disk managment is enabled, are you implying that Windows itself is not write-caching because the raid controller is overwriting it? Ultimatley I do not want within the OS to store any data in memory and then pass it onto the Raid Controller.

Sorry to seem a nuff nuff with concepts etc, however storage is not my forte and just need to ensure that data is being passed directly to the disk without any write-caching being performed at the OS level.


Just for record, there is write cache on the controller (with your BBU, so it is safe to use);  write cache on the HDDs (which is going to be disabled from factory with dell disks); and write buffer cache on the O/S.  

To disable from windows, just double click the my computer and let it show all the logical volumes.  Right click the RAID volumes, properties -> hardware -> select the picutre of the HDD, properties again and finally there is an option for the windows write cache buffer
Hi dlethe,

Thankyou for your response and clarification around the differnet types of caching and and where it is applied. The part you mention at the bottem regarding to disable it in windows is where i am getting stuck with the error and it will not let me change it. The attached pics reflect the area you mentioned to go into. So to me i would still assume that whilst write-cache is still ticked, the OS write buffer cache is still be utilised. This is what I need to and cannot disable.

Thanks Craig
Active directory policies can override write cache policy.  This is not the best link, but gives you enough to go on..  I'm sure an AD change at the domain controller will address this
(Boy that Dell popup is pretty confusing.  You would think it would clarify whether it is using the embedded controller cache or O/S.   If this popup does BOTH controller & O/S buffer cache, then they went out of their way to confuse you.

Somebody needs to learn something about designing a UI.
Confusing yes, and I'll admit to not reading your post carefully enough to know exactly what you're trying to do.  My comments were given with the [mistaken] assumption you were looking at hardware cache only:  It is common for people to want to enable/disable cache on their individual hard drives (maybe because they bought the latest 64MB cache version or for some other reason), but the drive cache on the individual drives is disabled and bypassed by the PERC, as it uses its own onboard BBU cache.  I'm sorry ... I'm afraid I couldn't tell you more about enabling/disabling OS write-caching.
No, I need to correct you PowerEdgeTech on the use of the HDD write cache on PERC (and the unbranded LSI equivalents).  I happen to be in the middle of a project where I am tuning the cache parameters and comparing the stock Seagate HDD settings with those of the same disks that LSI and others (i.e, Dell ships).

Specifically, there is much more than just the WCE bit (which is a single bit that programs "Write Cache Enable".).   THere are over a dozen parameters relating to cache that range from the max/min buffer sizes; cache queue algorithm; configurable settings for max & min pre-fetch blocks; cache segment size; .

Anyway, These settings are programmed into the HDD as factory defaults, and manufacturers set different values if they know how the HDD is going to be used.  Example, in a server config, default is to disable write cache, and then all the other settings can tune disks for transactional vs. large block vs streaming video.  

I'm doing work with tuning ZFS and have increased overall performance by over 20% by doing a few things to optimize for the most prevalent I/O block size over stock firmware.

The point here is that these controllers do NOT muck with any of these settings.  The controller has no idea how the HDD will be used, so, by design, they don't change any of the values.

If you are a consumer or end-user, you take what you get, but OEMs need to squeeze everything they can .. not only for performance, but perhaps for data integrity.   Things like recovery time limit, # of retries; disable transfers on errors .. have to be set to get a proper balance between having redundancy managed by either software or hardware-based RAID take over in event of a non-recoveralbe write error.

Anyway the PERC just leaves those settings alone.  It must.   The on-board BBU is a factor, but instruction reordering is one of the benefits of the cache.  The HDD can re-order I/O requests, or the controller can; and the cache  & programmable queue depths are all factors.  Not just in performance, but in data integrity, and dictate how a system deals with fault scenarios.

That's a fascinating read (and I don't mean to detract from the thread), and I would never disagree with you on points of drive and controller internals, but I was always under the impression that the PERC's disabled (which from what you said they can't/won't do) or simply ignored the hard drive cache.  I'd have to see if I could dig up some old Dell docs on the subject - maybe I misunderstood it.  So, you're saying that with controller's write-cache enabled that both controller and drive cache are used?  So getting the higher cache drives then - even in a RAID config - could be a benefit?  Sounds like a storage logistics nightmare to me - but probably only because I'm not as intimate with what happens under the hood.
Feel free to disagree any time , especially if you think I am wrong :)

Some controllers will let you manually override, and a few make some changes that are non-obvious that only a raid controller would really care about ... just to insure it operates correctly, but rule of thumb is that the OEM/FAE/developer whatever .. tunes the HDD settings to match both the RAID config (whether software or hardware); intended use; and performance vs data integrity trade-offs.

This one is  quite eye-opening, as I really didn't expect to see much of a difference and am fortunate enough to have hundreds of SAS-2 disks to experiment with, but to keep from saturating busses on the test systems I have to use distributed synthetic loads and sync them all up.  Sending I/O from multiple hosts into the same external enclosures and even looking at expander saturation.  Cool stuff. The test systems alone are 1/4 of a petabyte.  The "real" computer is one of those computers that you might of heard of in the news.  It has terabytes of RAM and a wiki page ;)
Thanks for the info.  That is cool stuff ... do you have a work "shadow" day :)  
Thanks guys, I will try disabling in AD and see if that works. Interesting how the error msg had the raid controller listed on top the the error window? Still thing that bloody continued had that option locked somehow.
Thanks guys, I will try disabling in AD and see if that works. Interesting how the error msg had the raid controller listed on top the the error window? Still thing that bloody continued had that option locked somehow.
Thanks guys, I will try disabling in AD and see if that works. Interesting how the error msg had the raid controller listed on top the the error window? Still thing that bloody continued had that option locked somehow.
Sorry about the spam :-)
Talk about deliberately confusing you with unnecessary facts, the PERC just refuses to accept the Windows setting since as previously mentioned this is set in OpenMangler. In contrast HP controllers pretend to accept the setting but ignore it.
wrong. the perc controller has no knowledge of the OS setting ... and it does not change the HDD settings for reasons I explained. this was a windows program that queried everything .. but the controller did not query the OS.)

... if you are going to troll, at least be correct in your posting)
That's not what I said, I said Windows tries to tell the controller to enable cache (treating it like a disk) and the Perc refuses to accept the setting. Windows initiates the conversation. not the controller.
I am sorry, I didn't read the thread properly, got distracted by reading the irrelevant stuff about you tuning disks for some supercomputer and missed looking at all the screenshots, didn't notice it was the bottom checkbox that was the problem. Should read customers posts rather than arguing with you.

Can't the "turn off windows cache" box be ticked without unticking the "disable write cache for device" box? Both the error status screen shots have this unchecked whereas it should be left checked since it's irrelevant.
Hi All,

dlethe: I could not find specifically where in AD group policy I could disable this. However I did find that many people where using group policy to push out commands to pc's which would utilise dskcache.exe ( to change windows cache settings. However when i run this utility i get error "Error setting Write Cache value. (1) Incorrect function." which means windows cannot control the windows disk cache and can only be chnage through manufacturing settings. Therefore i am thinking that it maybe the dell perc h700 drivers that are locking this.

andyalder: I can enable the tick box at the bottom "turn of windows write cache" however my understanding is to ensure that the OS is not handling any write-cahce operations, the top option "enable write caching on the device needs to be unticked and once this is done the bottom option becomes greayed out. This is how these options are stepup for all my other hosts which are using different controllers, its just this dell perc H700 controller giving me grief.
I wonder if you can just set userwritecachesetting and cacheispowerprotected to 0 in the registry. You would tell by the performance whather that disabled the windows write cache or not.
Avatar of Craig_hannagan

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I'd like to see it kept, I learnt something in this thread and that doesn't happen very often.
Can you point out which information might be making it worth to keep the question?
Recommend close with ID:34994307 as answer.
Implementing recommendation of participating Expert.

Zone Advisor