none
Event ID: 1539 Disk Write Cache inquiry RRS feed

  • Question

  • I'm new to these forums; so please excuse my inexperience if I'm posting to the wrong one.

    I have a Windows Server 2008 R2 Domain Controller on my network that is logging the above Event ID. It is referring to the PERC 6 RAID array where all of our shared folders reside; but this volume also contains the AD database. I configured the server in this fashion because I figured if the AD Database was on another volume and the Server OS crashed, it would be safe. It is also backed up daily.

    The RAID 5 configuration is only 3 physical disks. I am wondering if it is advisable to disable the write caching on the array; or should I just leave it as is? I've not seen any performance issues yet; but I am concerned with possible corruption of the AD DB and data loss.

    If I go to the volume properties for the 3 disks in the array I can disable the write cache on disk 0 and 2; but disk 1 warns that the write cache cannot be disabled. Most likely this is a BIOS setting for the RAID Controller that I'd need to make the change to.

    I guess my real question here is do I really need to worry about this event? I'd like to keep Write Caching enabled mainly because this volume houses the file shares and it would help in terms of performance. Is it common practice to house the AD DB on another volume; or am I just being paranoid?

    TIA for anyone that can provide some suggestions/guidance,

    -Peter

    Monday, September 26, 2011 5:38 PM

Answers

  • Dave,

    Thank you for the prompt response. You have a good point about the RAID config and we're taking steps to add another drive to the array. I'll also look into the possibility of moving the file shares as well. Everything resides on one server; but the workload is not very high on the file shares so I'm not too concerned about that. I'll check the article move forward from there.

     

    Thanks again! 

    Tuesday, September 27, 2011 7:27 PM

All replies

  • Peter, I would try the Directory Services forum.  However, I will try to answer your questions.  Why do you only have 3 physical disks in a RAID 5 set?  You know that losing one of those disks will be problematic.  The event ID is really talking about the link below which I have had customers hit before specifically when one of the drives in the system started having hardware errors.  With caching enabled, storage controller tells Windows that transactions are successful but in reality that is not the case causing corruption.

    You can leave caching enabled on the volume that contains the .dit if you are OK with possibility, while remote, of experiencing database corruption.  Assuming you have more DC's in the environment, and you have a failed DC, you could perform metadata cleanup of the failed DC, rebuild and dcpromo.

    Recommend you move file shares and that workload to another system or VM, leave AD by itself.

    The TechNet article  (http://technet.microsoft.com/en-us/library/ee410971(WS.10).aspx ) says:

    “Disk write caching is a performance improvement feature, which is available on most hard drives, that allows applications to run faster by making it possible for them to proceed without having to wait for data write requests to be committed to the disk. However, these delayed writes can result in data loss if a power outage or equipment failure occurs that causes the loss of the disk write cache data. Therefore, we recommend that you disable disk write caching on disks that host the Active Directory database.”


    Dave Guenthner [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights. http://blogs.technet.com/b/davguents_blog
    Monday, September 26, 2011 8:39 PM
  • Dave,

    Thank you for the prompt response. You have a good point about the RAID config and we're taking steps to add another drive to the array. I'll also look into the possibility of moving the file shares as well. Everything resides on one server; but the workload is not very high on the file shares so I'm not too concerned about that. I'll check the article move forward from there.

     

    Thanks again! 

    Tuesday, September 27, 2011 7:27 PM