Say we're going to use the same Raid-10 volume for both database and log, as both are sequential writes now, and say we have DAG with 3+ copies. What is the best practice for "read policy" -- Read-ahead; no-read-ahead; or adaptive read-ahead? Similarly, what is the best practice for "write policy" - Write-through or write-back? How about cache policy? Descriptions below: Read Policy Does my controller support this feature? See "Appendix: Supported Features." The read policies indicate whether or not the controller should read sequential sectors of the virtual disk when seeking data. Read-Ahead. When using read-ahead policy, the controller reads sequential sectors of the virtual disk when seeking data. Read-ahead policy may improve system performance if the data is actually written to sequential sectors of the virtual disk. No-Read-Ahead. Selecting no-read-ahead policy indicates that the controller should not use read-ahead policy. Adaptive Read-Ahead. When using adaptive read-ahead policy, the controller initiates read-ahead only if the two most recent read requests accessed sequential sectors of the disk. If subsequent read requests access random sectors of the disk, the controller reverts to no-read-ahead policy. The controller continues to evaluate whether read requests are accessing sequential sectors of the disk, and can initiate read-ahead if necessary. Read Cache Enabled. When the read cache is enabled, the controller reads the cache information to see if the requested data is available in the cache before retrieving the data from the disk. Reading the cache information first can provide faster read performance because the data (if available in the cache) can more quickly be retrieved from the cache than from the disk. Read Cache Disabled. When the read cache is disabled, the controller retrieves data directly from the disk and not from the cache. Write Policy Does my controller support this feature? See "Appendix: Supported Features." The write policies specify whether the controller sends a write-request completion signal as soon as the data is in the cache or after it has been written to disk. Write-Back. When using write-back caching, the controller sends a write-request completion signal as soon as the data is in the controller cache but has not yet been written to disk. Write-back caching may provide improved performance since subsequent read requests can more quickly retrieve data from the controller cache than they could from the disk. Write-back caching also entails a data security risk, however, since a system failure could prevent the data from being written to disk even though the controller has sent a write-request completion signal. In this case, data may be lost. Other applications may also experience problems when taking actions that assume the data is available on the disk. <image001.gif> NOTE: Storage Management does not allow you to select the Write-Back policy for controllers that do not have a battery. This restriction protects a controller without a battery from the data loss that may occur in the event of a power failure. On some controllers, the Write-Back policy may be available in the controller BIOS even though it is not available in Storage Management. Force Write Back. When using force write-back caching, the write cache is enabled regardless of whether the controller has a battery. If the controller does not have a battery and force write-back caching is used, data loss may occur in the event of a power failure. Write Back Enabled. When using write-back enabled caching, the controller firmware disables the write cache if it does not detect the presence of a charged battery over a specified period of time. For example, on some controllers, the write cache is disabled if the firmware cannot detect a charged battery within 72 hours. Write-Through. When using write-through caching, the controller sends a write-request completion signal only after the data is written to the disk. Write-through caching provides better data security than write-back caching, since the system assumes the data is available only after it has been safely written to the disk. <image001.gif> NOTE: Write-through is the default write policy setting when cluster mode is enabled. In cluster mode, the PERC 3/DC, 4/DC, and 4e/DC controllers only allow write-through caching. Write Cache Enabled Protected. When the write cache is enabled, the controller writes data to the write cache before writing data to the physical disk. Because it takes less time to write data to the write cache than it does to a disk, enabling the write cache can improve system performance. After data is written to the write cache, the system is free to continue with other operations. The controller, in the meantime, completes the write operation by writing the data from the write cache to the physical disk. The Write Cache Enabled Protected option is only available if the controller has a functional battery. The presence of a functional battery ensures that data can be written from the write cache to the physical disk even in the case of a power outage. <image001.gif> NOTE: Storage Management does not allow you to select the Write Cache Enabled Protected policy for controllers that do not have a battery. This restriction protects a controller without a battery from the data loss that may occur in the event of a power failure. When using the Create Virtual Disk Advanced Wizardon a controller without a battery, the wizard will either display Write Cache Disabled as the only available option or the wizard will display no option at all for write policy. Write Cache Disabled. This is the only available option if the controller does not have a functional battery. Cache Policy Does my controller support this feature? See "Appendix: Supported Features." The Direct I/O and Cache I/O cache policies apply to reads on a specific virtual disk. These settings do not affect the read-ahead policy. The cache policies are as follows: Cache I/O. Specifies that all reads are buffered in cache memory. Direct I/O. Specifies that reads are not buffered in cache memory. When using direct I/O, data is transferred to the controller cache and the host system simultaneously during a read request. If a subsequent read request requires data from the same data block, it can be read directly from the controller cache. The direct I/O setting does not override the cache policy settings. Direct I/O is also the default setting.

your storage vendor would provide those recommendations. check out the esrp for your storage vendor, these docs would have these settings. http://technet.microsoft.com/en-us/exchange/ff182054.aspx

your storage vendor would provide those recommendations. check out the esrp for your storage vendor, these docs would have these settings. http://technet.microsoft.com/en-us/exchange/ff182054.aspx

Hi I am not familiar with hard disk. . Exchange DB and caching hard disks and controllers. http://support.microsoft.com/kb/188589Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.