Write Cache on Domain Controller File Servers 1

[Goid]

I have 30 sites connected via VPN with domain controllers in each site that also act as file servers. All of these servers are physical. I have had issues where a change was made in the login script, but this change did not make it to a certain DC. I discovered that the FRS had quit working and I had to take JRNL_WRAP restore procedures to get it to function properly again. I have discovered that write caching is enabled on the disk. This is a RAID controller with volumes C and D residing on the same physical disk (3 disk RAID5 with HSP) split into 2 logical volumes (C and D). My question is what is the best practice in this situation. I have read about a huge performance degredation when write caching is disabled and I know that domain controllers by default are supposed to have write-caching disabled. But this is not the case in my scenario. My volumes are only presented as one physical disk to the server, so disabling write caching would be for both the C and D. Also, why is write caching enabled in the first place? It seems the problem was caused by the C volume filling up and FRS being unable to write it's changes. Of course the best practice here would be to monitor the disk space, but other than that does anyone have suggestions?

 

[technome]

Having the raid cache enabled or disable is not the cause of the JRNL_WRAP. Raids work at a lower level then the OS and will not affect the OS unless there is a bug in the firmware/driver causing corruption/delays, which is extremely rare, that is with battery equipped raids .

To be technical, it not the disk cache but the raid cache your are referring to, unless you are using a very low end raid interface. Microsoft is referring to the cache on the disks themselves. On DCs hanging off standard disk interfaces, MS can disable the disk caches. On high end raids, raid manufactures write code which MS can not control, as it should be (in most cases the disk cache is turned off by the raid driver anyway). High end raid adapters give the option of write back or write through (or the equivalent)as to their card's cache. If you disable write back you will get absolutely dismal performance. Leave write back enabled.

"why is write caching enabled in the first place?" If it is disabled, every single write request must complete before more is written to the disk. If you have many users hitting the disk, you can imagine the delays, and the drives heads are overworked. If cached, the write go to the cache, and are written more efficiently. The drives heads can write multiple (and larger) writes in a single motion across the drives, unlike write through.


........................................
Chernobyl disaster..a must see pictorial

http://www.kiddofspeed.com/default.htm

 

[Goid]

Thanks for clearing this up technome. The reason why I thought the JRNL_WRAP was related to the disk cache was because the event I received indicated the FRS could not write to the disk, so I thought this may be related to write caching. But thinking back on this, the fact that the disk ran out of space was the likely issue for the JRNL_WRAP error.

Thanks again!!

 

[technome]

Ran into a couple jrnl_wrap(s) due to very low disk space.



........................................
Chernobyl disaster..a must see pictorial

http://www.kiddofspeed.com/default.htm

 

[theravager]

Common cause of this is the intial promotion of the DC's having themselves as the primary dns.