PERC H710 and Windows Server 2008 r2 Write Caching policy

Controller has a BBWC, so a power failure shouldn't be an issue?

Simon

Write caching on the drives is taken over via the raid driver as a precaution against data loss due to power issues, drive failures, memory issues and raid controller issues etc.....basically it fairly dangerous to have enabled. If you want to persist you could possibly use a windows startup script; hopefully you maintain a reliable backup schedule.

http://support.microsoft.com/kb/811392

Simon Weel,

Write caching will be controlled by the Perc H710, not the OS. That is why it won't stay enabled.  So you may want to check the setting in the controller BIOS (CTRL-R on boot) and see if it is configured in there. After setting reboot and see if drives quiet as before.

Let me know how it is going.

Checked the controller BIOS settings. I created two RAID1 virtual disks. One consists of two SAS drives. The other virtual drive is made up of two SATA drives. For both, the write policy is set to Write Back.

If I check the settings with iDRAC, it reports the write policy for the SAS drive as Write through and Disk Cache Policy: Disabled. For the SATA drive, it reports Write back and Disk Cache Policy: Default.

When I check Windows Device manager > Disk Drives, the Write Caching policy and Turn off Windows write-cache buffer for the SAS-drive is off. For the SATA drive, both are on.

As soon as I change the setting for the SAS drive in Windows Device manager, Ie, enable Write Caching and Turn off Windows write-cache buffer the setting in iDRAC changes to Write Back but remains Disk Cache Policy: Disabled.

PERC H710, firmware 21.2.0-0007. Windows driver 6.801.5.0.

Simon

"Controller has a BBWC, so a power failure shouldn't be an issue?"

A battery backup only protects from a power failure, it does not cover any of the other failures I mentioned, that is why it is still dangerous.

The "policies" you set in Windows device manger are independent, and different as to the policies set on the raid either via the raid bios or Open Manage on the h710. Write back/write through are policies ONLY related to the raid controller, they do not exist in Windows. The raid policies have nothing to do with the cache on the physical drives themselves, nor does the controller want to deal with data which is cached on the drives PCB board chip.  There are a few low end, "wannabe raid adapters" sold as Percs which can control disk cache, the h700 is not one of them. 

If you set the drives to cache in Windows device manger, if you lose a drive, lose power etc, everything in the drives cache is history, not much of an issue with reads but a big problem if the drives cache was filled with writes. On the other hand the raid controller's write polices are protected, as the writes are in battery protected ram, so no matter what failure (except if the raid battery fails, or the adapter dies an instant death), your data is protected . 

 

 

 

Oke, problem solved. Changed the setting in Dell Server Administrator > Storage > PERC H710 > Virtual Disks > Available Tasks > Change Policy > Execute. Read policy: Adaptive Read Ahead. Write Policy: Write Back. Disk Cache Policy: Enabled. After a reboot, the checkmarks for disk caching in Windows Device Manager are set.

Weird though, that these settings can't be made using the controller BIOS? Or I missed something....

Simon

Hmm, spoke too soon. Seems like the settings still don't survive a reboot.... Problem is acknowledged by Dell and they are working on a solution.

Simon

Have to give you a plus mark for persistence, but you could be dangerous...

Dell will NOT re-write the firmware/driver to allow the drives disk cache to be enabled. Hopefully the issue is a bug, not related to the drive cache, which they might fix.

 

 

 

Hi

I have the same issue on PE T320 with H710 RAID controller

French DELL Support have no idea about the problem.

Have you any news from US support?

Thanks!

FBH

TITELIVE France Technical support.

Hello!

I have the same issue on an T320 with PERC H710 (Windows Server 2008 R2 SP1 Domain Controller). I can set the cache policy in Dell Server Administrator to Write Back, but after the next reboot it changes to Write Through again. German Support and escalation to French System Engineer brought nothing in the first place. They want to sell me it is not a bug but a feature against data loss... :-P

I say this ist absolute b.s! I installed and administered Dell PE Servers for the last 15 years and this is the first time that this happens on an RAID controller with a battery backup. Even in the H710 User guide it says: "Write-Back caching is used under all conditions in which the battery is present and in good condition"

I also compared to a T610 with a PERC H700 (Windows Server 2008 R2 SP1 DC too) and the problem did not show up. But the T610 has very old firmwares and drivers.

Does anybody know a supported workaround ?

Thanks!

Thank you for your reply.
This is exactly what I found.
The problem is that : the windows writing cache is linked to the controller H710 cache writing policy;  
when windows disable disk caching > write back policy on RAID controller is automatically disabled (abnormal) 
I did the test with a Perc 6 / i: the controller writing policy  does not change whatever settings on windows disk cache.

The DELL support proposes me a False solution : Forcing windows to keep Enabled disk cache. its not a solution, just a problem hiding.

For me this is a bug but DELL technicians are either uninformed or too proud to recognize.

I just talked to Dell again - they now admit it is a problem with the H710 and should be fixed with a firmware update in june.

 

Actually, windows DOES have it's own cache settings and cache management be it running a USB HDD, USB Raid array, on board or pci raid, etc

Granted there are raid controllers out there with 4,6,8,16 etc GB of memory for caching. On those, the drivers/software must control them, and setting THAT to write back is very dangerous.

A GOOD raid drive SHOULD disable window's read and write caching system for THAT controller and drives on it ONLY - and that's ONLY if that controller has dedicated cache memory (I'm talking decent memory here.. not 64KB, not 64MB.. I'm talking at least 2GB)...that way the controller can handle the cache which should be MUCH faster than system memory. But depending on what the computer does, you may need a HUGE cache... and then it's cheaper to load the machine up with 32 or 64GB of ram and edit the registry to enable large disk caching.

But no matter what, Windows STILL has it's own drive caching system that will use system memory for read & write through caching - even write back if you know where to look (depending on the version of Windows)

Windows caching, even write back is much safer. As long as you have some form of power backup, you are ok - for the most part, but if you BSOD, lock up crash... basically anything that prevents windows from dumping the cached data to disk is lost... and if the MFT that hasn't been written to yet.. yikes...

Also if you backup your system daily, with FULL back ups now and then and daily incremental, any corrupted files can be recovered. On my home system, I have a 16TB Raid 0 Buffalo USB 3.0 exteral raid unit.. My system does a incremental backup every 4 hrs. I don't really notice it when I'm using my PC.. it takes about 5 mins or less. In a production environment, incremental can take hours.

Anyway, if you have a raid controller with it's OWN cache memory. Write back on that is doubly dangerous as you have windows write caching the drives/controller and the controller doing it's own caching. I do not recommend this is ANY way shape or form. in this cache, windows should be set to read only cache, or shut it off entirely, and let the controller do it all. It will be faster, and wont use system memory. A power backup will protect against most issues, but the above issues will still persist this way.

However there is still another danger... I've seen data loss this way from a SIMPLE POWER DOWN of the machine because server shuts down before the controller can dump the cached data... 16GB of cached data doesn't dump in just a few seconds. Depending on the speed of the array, it would dump at 50-300MegaBytes per second. It's not limited by sata or the system here, but physical disks are still slow. This is a RARE thing as the drivers should NOT let windows shut down until it's given the OS the go ahead that all buffers have been flushed

But I will say, write back, produces AMAZING results when you have more than one application/user doing heavy work on a disk or an array. Otherwise the disks ARE going to thrash, and they will be significantly slower. Why? Well because data is written, REAL TIME.. and IN ORDER. With write back (either in Windows or on the controller), data is written to memory, and the OS/application(s) are told the write operations were successful. So the application you are using can execute other hard drive command or no longer "Freeze up" waiting for data to write. It also lets the os and other applications write at once... here's why it doesn't thrash.. rather that write data in order, Windows (or the controller), will write the data to disk, as needed, in the most optimal way an minimize seek times (movement of the read write heads) to write data in the most efficient way possible. Granted there are some things that STILL must not be written out of order. Usually this happens without incident.

My advice is, how much downtime can the machine have? and how long to do a system restore, a backup restore, etc in case you do get corruption? If It's a home machine like mine.. GO FOR IT... the most I'd lose is 4 hrs of data.. BUT I don't write back C: (Windows drive). That's on write through. my D: drive IS on write back, and that's where 90% of everything I run is kept

Sometimes in a business environment you HAVE to use write back otherwise you simple will not get the speed you need. You can keep slapping on disk after disk after disk in varying raid configurations. But again... you must go back to.. how often do you back up... is the backup power in good working order? and how long to replace a few corrupt files (or registry)? and how long for a TOTAL restore.

Lastly.. NEVER put the system drive on write back!!! This way you won't corrupt your OS, and you can always get the machine to boot up If you do write back.... do it on a DATA drive.

Now that usb 3.0 can do speeds as fast as Sata 3.. well pretty close as usb 3 is 5Gbits/sec and S3 is 6... s3.2 is 16... but you do see many of those drives and they are pricey.. nor do you see many mobos and controllers with them.

Anyway, if you have a usb 3 raid system. I have one. That's my D drive! (and it's backed up by another usb 3 system).. and both are on the same UPS as my PC... when the power is lost.. or even if the computer BSODS, crashes, etc... The boxes NEVER lose power! So they can dump their cache. On power failure, my system does a shutdown when the APC is at 95%... My PC will shutdown in no more than 60 seconds... then that leaves just my business cable modem, router/hub/AP, and my external raid devices.. the usb raid boxes will auto shut off once their cache buffers are flushed... then that APC can keep my internet/wifi going for 3 hrs

Hawthornecub...

How long have used mid/high end hardware raid controllers?   Can't be very long. 

 

For anyone wanting to enable the drive caching via Windows device manager, not referring to raid adapter battery backed caching ( as in write back, WB)....

Well one of my clients  had a Perc H200 on a T310. To have ANY performance the drive caching needed to be enabled (the system has a large oversized BBU).  As careful as I could be the server was downed without the drives flushing the data properly... once due to an early AM power utility issue, and once due to a server freeze due to a driver install. End result, the raid1 ended up with so many "punctured" sectors (continuously growing number, soft errors, no  physical errors) I had to upgrade the controller to a Perc 6i which has onboard cache/battery and  Patrol Reads. Used higher end Lsi based (Perc) battery backed caching controllers for years and never had this issue . So if you want the same issue, just purchase one of the low end, (non battery backed, non caching) Percs, so you can enable the cache on the physical disks.