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

Question

Just installed Rapid Recovery 6.1 on Windows Server 2016. Have 18.6TB of disk, wanted to create an 18TB repository. The error I'm receiving says you can't exceed 16TB with write caching policy on (and yes, I know I have to increase the cluster size). Saw that the recommended setting for Windows 2016 is to leave write caching on. 
 So I'm confused. Do I leave caching on and create two 9TB locations (example K:\Repo1\Loc1 and K:\Repo1\Loc2) to get 18TB repository? That seems silly to me. Do I turn caching off and create a 18TB repository? Which doesn't seem right either.

Tim Seymour · Answer

The only time we recommend turning off caching is in Server 2008 R2. That is because we see high paged pool RAM usage in that scenario when write caching is on for the repository. 
 
I have not seen this issue before with Rapid Recovery 6.1 and I just created a 40 TB repository the other day without any issue. I'd recommend either creating a repository with 2 extents or opening a support case so that we can troubleshoot. There should be no file size limitation as far as I know in Server 2016 that would block the creation of a large repository.

Tudor.Popescu · Answer

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\\FileConfigurations\\Specification\WriteCachingPolicy = 3 where = a Guid and = 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.

JonnyFofo · Answer

This has been identified as product defect RR-102507 and will be fixed in a future release. 
 
I have existing large Repo's (40+TB) that were created in an earlier version of the software, the new version will not let me add new large storage locations to these existing Repo's, unless I disable the cache first. I disabled cache, then I added the large storage locations to my Repo and re-enable cache. 
 
I found the problem mentioned here: 
 support.quest.com/.../227257