Creating Large Repository - Multiple locations or turn off write caching policy?

Hi dlh:
So, the hardware cache is probably the disk level cache which is managed by the storage controller or the storage controller cache. There are a few options here; the safest is to have the disk cache disabled and the storage controller enabled and set to "writeback". If the Storage controller does not have an on-board cache this may not be possible (and caching is set automatically to write through). In this case, you may get a little extra performance by enabling the disk cache on each physical disk but take the risk of data corruption if one of the disks fails during a write operation. Most customers make a few performance tests before deciding how to deal with the disk cache. Again, everything above is related to hardware. The second element is the Windows cache which, basically does the same thing albeit slower and at a larger scale (keeps data into memory until it can be committed to disk). This is why, when you copy large amounts of data, you see the copying operation start very fast (as it is cached in the memory) and then slowing down as it needs to be committed to disk. My personal opinion is that Windows caching has very little impact on Rapid Recovery performance and the byproduct of saving a lot of memory when caching is disabled, it is well worth a minimal loss in performance. (By the way, to check if the caching policy is set to disabled, please check if HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Core\Repositories\<RepositoryID>\FileConfigurations\<ExtentNumber>\Specification\WriteCachingPolicy = 3
where <REpositoryID> = a Guid and <ExtentNumber> = an integer (in your case it is 0)

These being said, I would like to ask you to check if SecureBoot is enabled (and disable it if it is). To do so, please run msinfo32.exe and scroll down to "Secure Boot State" in the System Summary. The reason is that the aavdisk driver does not run if secure boot is enabled. Although aavdisk is related to mounting volume there may be a check that is performed in relation with it.

If the issue persists, please open a case with support and we will try to determine together what is the cause of the issue you are dealing with.

Hi dlh:
So, the hardware cache is probably the disk level cache which is managed by the storage controller or the storage controller cache. There are a few options here; the safest is to have the disk cache disabled and the storage controller enabled and set to "writeback". If the Storage controller does not have an on-board cache this may not be possible (and caching is set automatically to write through). In this case, you may get a little extra performance by enabling the disk cache on each physical disk but take the risk of data corruption if one of the disks fails during a write operation. Most customers make a few performance tests before deciding how to deal with the disk cache. Again, everything above is related to hardware. The second element is the Windows cache which, basically does the same thing albeit slower and at a larger scale (keeps data into memory until it can be committed to disk). This is why, when you copy large amounts of data, you see the copying operation start very fast (as it is cached in the memory) and then slowing down as it needs to be committed to disk. My personal opinion is that Windows caching has very little impact on Rapid Recovery performance and the byproduct of saving a lot of memory when caching is disabled, it is well worth a minimal loss in performance. (By the way, to check if the caching policy is set to disabled, please check if HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Core\Repositories\<RepositoryID>\FileConfigurations\<ExtentNumber>\Specification\WriteCachingPolicy = 3
where <REpositoryID> = a Guid and <ExtentNumber> = an integer (in your case it is 0)

These being said, I would like to ask you to check if SecureBoot is enabled (and disable it if it is). To do so, please run msinfo32.exe and scroll down to "Secure Boot State" in the System Summary. The reason is that the aavdisk driver does not run if secure boot is enabled. Although aavdisk is related to mounting volume there may be a check that is performed in relation with it.

If the issue persists, please open a case with support and we will try to determine together what is the cause of the issue you are dealing with.