Hey @Onno van den Berg , I’m not finding anything either.

I’ll get with the docs folks to get this answered and added to the documentation.

I found mention of it here: https://documentation.commvault.com/11.26/expert/144008_changes_in_user_interface_in_feature_release_1125.html

Following changes are made to the Disk Configuration page: - A new "Cache Configurations" tile with an "Enable" toggle key, has been added. - When the "Enable" toggle key is moved to the right, a new "Metadata Cache" section appears. If you click the Path link you can modify the path.

Now to find out what metadata cache means (I imagine it’s a temporary staging location similar to our JobResults directory but will need to confirm...).

Internally I can see something relating to this feature mapped to live browse. I suspect this is similar to tied cloud library where metadata is kept on the hot tier to increase performance of lookups. Instead, with this, metadata could be kept locally on a Media Agent.

Pure speculation at this point, but it makes sense since it would dramatically speed up retrieval of data since we won’t have to download the metadata first for lookups.

Hi @Damian Andre I think you are right and a similar feature was available feature was available for some time in the CommCell console. I tested it and gave feedback and at some point in time it was removed. It was primarily meant to speedup aux-copies and required the configuration of a disk library which I found very cumbersome and it was tight to a single MA. 

So I assume this is the improved implementation but would like to get some clear understanding if it is actually the case and in regards would like to get some information like:

• What is the use-case.
• What can you expect in regards to performance, assuming it is indeed impacting performance. A rough estimated based on internal testing would at least give some indication if it is worth using it. 
• Does it require specific underlying storage for example NVMe/SSD based backend storage which really speeds-up the lookup and thus operations. 
• Space calculation.
• Does it work in case of multiple MAs sharing the same mount paths which in case of cloud libraries is pretty common.

Yes, it is new and improved solution with support for multiple MAs sharing the same data path and granular caching of metadata extent for space efficiency

1. This cache is beneficial for live browse and file indexing operations. By caching metadata, and serving it from the cache, we avoid any potential delays that can be caused due to subpar random IO performance on the cloud storage (most cloud storage are optimized for sequential and large reads) or deep archive or cold storage types.
2. 5X performance improvement for file indexing job and noticeable performance improvement for live browse enumeration. Since this is a metadata cache, there would not be much impact for “restore jobs” performance except when restore job is dealing with million of files (and metadata outweighs data). Also, performance improvement varies and could be more in case we are dealing with slower cloud access.
3. No, it does not require NVMe or SSD as such.
4. 5% of the VM size. We do granular caching for the most part i.e. cache only clusters 4K-64K hosting the metadata. Earlier we used to cache entire extent (1MB) hosting the metadata which was more space consuming.
5. Yes, it works with multiple MAs now.

@Pratik Rana thanks for the detailed response! one last question is what would happen if you run into disk space issues? 

Can you please make sure this feature is properly documented ? 

We perform periodic pruning with limited retention of cached contents. Also, some of the pruning kicks in when low space is detected.

I will check with the documentation team. This should be documented in SP26 under “configuring live browse cache for virtual machines”.