Difference between revisions of "IBM CMOD Cache Filesystems"

If you have more than one cache filesytem, OnDemand chooses the cache with the most free space, and puts the compressed objects generated by the load there.

CMOD Cache expiration is the process by which OnDemand reduces the amount of data inside the caches, in order to make room for new data that is loaded into your Content Manager OnDemand server.  It does this by removing data that has already been migrated to secondary storage or is otherwise eligible for expiration - starting with the oldest documents first - until the filesystems are approximately 80% full by default.  As mentioned above, on large IBM CMOD servers that have multiple terabytes of cache, adjusting the minimum and maximum parameters makes optimal use of the expensive storage that the CMOD cache is built with.  The only reason to maintain an excessive amount of free space in your cache is to ensure there is room to load incoming files if data can't be written to secondary storage for some reason.  You can visit the [[arsmaint]] page to find out more about how you can create free space in the IBM CMOD cache filesystem.

Fast and reliable storage is expensive and finite.  In order to make the most out of the space you have in your IBM CMOD Cache filesystems, you must store more of the data that users are actually accessing, but only for the period of time that they are actually accessing them.  It's possible to optimize the cache contents so that you’re using precisely the amount of disk necessary to quickly perform the required retrievals, but still have enough space to load new data.  An optimized cache contains only the data people are accessing.  Unfortunately, there's no built-in tool for performing the Content Manager OnDemand Cache, but [https://cmod.cloud/ibm-cmod-cache-optimization/ CMOD Cache optimization] is offered as a service by companies that specialize in [https://TenaciousConsulting.com IBM CMOD Professional Services].

If your IBM CMOD Cache Filesystems are large (for example, 1 terabyte / 1000 gigabytes) then the default setting for the <code>arsmaint -c </code> will leave 20% - 200 gigabytes of empty cache.  If you have multiple 1TB cache filesytems, and you only load 20GB per day, you could have a huge amount of wasted space in your caches.  You can adjust this number with the <code>-n </code> and <code>-x </code> options for [[arsmaint]] to set new maximum and minimum caches sizes during cache expiration.

The other ways to tune the cache filesystems are to analyze the patterns of retrievals of Application Group data, and change the cache retention to match actual end user usage, and to use data from your load and retrieval patterns to determine your optimal cache size.

NO!  The cache is only to be managed with the [[arsmaint]] utility!  The structure of the OnDemand Cache Filesystem is complex, and deleting files or directories inside the Content Manager OnDemand cache could lead to documents becoming unavailable to end users, and potentially irrecoverable data loss.

If you have a backup of your cache data in your enterprise backup system, you can probably recover the missing data.  Contact a company that provides [https://cmod.cloud/professionalservices/ Professional Services for CMOD] for assistance in recovering data.  They have tools to help you restore and verify the contents of your cache, or to pull data from secondary storage back into the CMOD cache.

Content Manager OnDemand automatically balances the amount of data in caches by placing new CMOD object files in the cache with the most free space, measured in blocks of free space in the filesystem.  If you have a large number of cache filesystems with dramatically different utilization, you probably have a configuration issue that needs to be corrected.