1. Read cache for each logical drive (RAID array)
2. Write cache for each logical drive (RAID array)
3. Write cache for each physical disk (on each HDD or SSD)

The cache settings can be changed at any time without affecting your server's operation, and does not need a system restart for the settings to take effect.

Read cache for each logical drive (RAID array)

• Enabled—The controller transfers data from the logical drive to its local cache in portions equal to the stripe size. Use this setting for the best performance when workloads are steady and sequential.
• Disabled—The controller transfers data from the logical drive to its local cache in portions equal to the system I/O request size. Use this setting for the best performance when workloads are random or the system I/O requests are smaller than the stripe size.

1. In the Enterprise View, select a controller, then select a logical drive on that controller.
2. On the ribbon, in the Logical Device group, click Set Properties. The Set Properties window opens.
3. In the Read Cache drop-down list, select Enabled or Disabled, as needed.
4. Click OK.

Write cache for each logical drive (RAID array)

The write cache setting determines when data is stored on a disk drive and when the controller communicates with the operating system. You can set the Write Cache to:

• Disabled (write-through)—The controller sends (or writes) the data to a disk drive, then sends confirmation to the operating system that the data was received. Use this setting when performance is less important than data protection.
• Enabled (write-back)—The controller sends confirmation to the operating system that the data was received, then writes the data to a disk drive. Use this setting when performance is more important than data protection and you aren't using a battery-backup cache or zero-maintenance cache protection module.
• Enabled (write-back) when protected by battery/ZMM—Similar to Enabled (write-back), but used when the controller is protected by a zero-maintenance cache protection module (#3AFM700).

Note: (RAID 10, 50, and 60 only) All logical drives comprising a RAID 10/50/60 logical device must have the same write cache setting—either all write-through or all write-back.

To quickly change the write cache setting:

1. In the Enterprise View, select a controller, then select a logical drive on that controller.
2. On the ribbon, in the Logical Device group, click Set Properties. The Set Properties window opens.
3. In the Write Cache drop-down list, select Enabled, Enabled when protected by battery/ZMM, or Disabled, as needed.
4. Click OK.

Write Cache Policy for an Individual Drive

Note: You can change the write cache setting for an individual drive only if the Global Write Cache Policy is set to "Drive Specific."

By default, disk drive write caching is disabled in maxView Storage Manager. To enable or disable write caching on an individual drive:

1. In the Enterprise View, select a controller then, in the Physical Devices tree, select a disk drive.
2. On the ribbon, in the Physical Device group, click Set Properties. The Set Properties window opens.
3. In the Write-back Cache drop-down list, select Enabled or Disabled.
4. Click OK.

Introduction

The Benchmark

• Compucon Workgroup SX E3 server
• Intel Core i3 7100 processor (2C/2T, 3.9GHz, 3M cache)
• 8GB ECC memory (DDR4-2400 Single Channel)
• Microsemi Adaptec 8405 RAID controller
• ADATA SX950 240GB SSD x3

Drivers/Firmware:

• X11SSM-F BIOS revision 2.0a
• Adaptec 8405 firmware v7.11.0 build 33173
• Adaptec 8405 driver v7.5.0.54013
• ADATA SX950 firmware level 5A

Software:

• Microsoft Windows Server 2016
• Passmark Performance Test v8.0 build1054
• Crystal Disk Mark v5.1.2 x64
• Anvil's Storage Utilities v1.1.0.337

• Performance Test - Defaults (200MB test file size, block size 16KB)
• Crystal Disk Mark - Defaults (1GiB test file size, average of 5 test runs for each test)
• Anvil's Storage Utilities - 1GB test file size, 8% data compressibility

• RAID 0 of 3 x 240GB disks
• RAID 1 of 2 x 240GB disks
• RAID 5 of 3 x 240GB disks

1. Logical device controller read cache [ON | OFF], hereafter referred to as Array Read cache;
2. Logical device controller write cache [Write-back or ON | Write-through of OFF], hereafter referred to as Array Write cache;
3. Physical device write cache [Write-back or ON | Write-through or OFF], hereafter referred to as Disk Write cache.

Performance Test Results

This benchmark application contains a number of tests that exercise the mass storage (the RAID array in this case) connected to the computer. The C: drive is used for the test, where the OS, applications, and test data all reside.

The test file size is 200MB and the read or write block sizes used are 16KB. Each test uses uncached asynchronous file operations (with an IO queue length of 20), and each test runs for at least 20 seconds.

Sequential Read: A large test file is created on the disk under test. The file is read sequentially from start to end.
Sequential Write: A large file is written to the disk under test. The file is written sequentially from start to end.
Random RW: A large test file is created on the disk under test. The file is read randomly; a seek is performed to move the file pointer to a random position in the file, a 16KB block is read or written then another seek is performed. The amount of data actually transferred is highly dependent on the disk seek time.

• The Sequential Write test performs well when the Array Write cache is turned on (x1x). With the test file size being 200MB in size only, the data set can comfortably fit inside the RAID controller's cache (1GB in size) and we do not need to wait for the data to be written to the physical disks.
• There are no obvious patterns for the controller read cache setting, likely due to the lack of 'hot data' for the controller to store in the cache for frequent reading purposes. Hot data is data that is accessed and read repeatedly.
• Configurations #7 and #8 (011 and 010) looked good initially, but with the addition of the second and third runs for configuration #1 their appeal is now questionable. To gain any further insight we may need to run a lot more tests if we were to rely on Performance Test alone. We can place more emphasis on results from the other two benchmark applications as an alternative.

Crystal Disk Mark Results

• The test file size is 1 Gibibyte in size and can therefore not fit in the RAID controller's cache. The results are therefore not affected by the controller cache anywhere near as much as in Performance Test.
• Leaving all caching ON (configuration #1, 111) appears to be an optimal and balanced approach for systems that require both sequential and random read/write patterns.
• Turning off the array write cache (configuration #3 and #6, 001 and 101) are viable options as it increases random write performance significantly at the expense of sequential write performance. Servers that are serving multiple users and databases most of the time will benefit. Configuration #6 (101) is more appealing as the array read cache lifts its random read performance (whereas configuration #3 suffered).
• As the benchmark runs every test 5 times and then presents an average score, the results are more reliable and reproducible. We ran additional test runs and can confirm this point.

Anvil's Storage Utilities Results

• The results are quite similar to the results produced by Crystal Disk Mark:
  
  • The test file size is 1 Gigabyte in size and therefore can not fit in the RAID controller's cache. The results are therefore not affected by the controller cache anywhere near as much as in Performance Test.
  • Leaving all caching ON (configuration #1, 111) appears to be an optimal and balanced approach for systems that require both sequential and random read/write patterns.
  • Turning off the array write cache (configuration #3 and #6, 001 and 101) are viable options as it increases random write performance significantly at the expense of sequential write performance. Servers that are serving multiple users and databases most of the time will benefit. Configuration #6 is more appealing as the array read cache lifts its random read performance (whereas configuration #3 suffered).
• Configuration 7 with all caching turned on except array read cache produces the best result if and when sequential read performance is not important. A possible theory to explain this phenomenon is that the controller no longer needs to spend processing cycles to recognise what data is hot and therefore should be kept in cache. On the other hand, this being a synthetic benchmark means an array read cache may not be as useful here and may not reflect performance in a production environment.

Conclusion

In general:

• We highly recommend all servers to be protected by a UPS at all times. The batteries within a UPS have a finite lifetime and should be tested as often as practically possible to ensure the UPS will actually work in the event of an actual power failure. Good preventitive maintenance would be to replace the batteries at least every two years.

• We recommend all caching to be turned on for optimal performance:
  • Logical device controller read cache [ON]
  • Logical device controller write cache [Write-back]
  • Physical device write cache [Write-back]

• For utmost data integrity, installing a CP module (cache protection module, also known as BBWC or ZMCP) will help when the physical device write caches are turned OFF (Write-through). This protects any data from being lost in the event of an AC power failure at the wall socket, a faulty UPS, or a power supply unit hardware failure within your computer system. Write performance will suffer (see configuration #2 in the benchmark results).

We did not find any evidence to suggest that following Adaptec's advice of disabling all caching (for arrays made up of all SSD drives) to be a good idea. While some of our benchmarking revealed potentially good cache settings for particular data storage patterns (such as for heavy random write performance), the synthetic tests were likely unable to make use of the controller's read cache as most of the testing had data that is randomly generated at runtime.

For advice on how to change cache settings, please see Changing Read and Write Cache settings.

END