Summary

When a disaggregated node starts with the PALI block cache disabled (disaggBlockCacheSizeBytes=0 or disaggBlockCacheNumShards=0), initBlockCache() does not create a cache object. Setting disaggBlockCacheSizeBytes to a positive value at runtime then updates the parameter but cannot enable the cache: the on_update callback finds no cache to resize (getBlockCache() returns nullptr) and nothing re-runs initBlockCache(). As a result getParameter reports the new size while the cache stays disabled until the node restarts.

Raised during review of the SERVER-129474 PR (#56406). That PR intentionally returns OK from on_update in this case rather than erroring, because on_update also fires at startup (before the cache exists) and the IDL stores the value before invoking on_update – so an error would neither roll back the value nor be safe at startup (it would break the startup configuration path).

Review comment: https://github.com/10gen/mongo/pull/56406#discussion_r3449349168

Proposed Solution

Support enabling the block cache at runtime by constructing the cache object when disaggBlockCacheSizeBytes transitions from 0 to a positive value (and tearing it down on the reverse), instead of only creating it during PALI initialization. This must handle the per-handle cache pointer (pali->blockCache) safely with respect to concurrent readers.

As an interim measure, SERVER-129474 adds a warning log when a runtime size change cannot be applied because the cache was not initialized.

Definition of Done

• Setting disaggBlockCacheSizeBytes to a positive value at runtime on a node that started with the cache disabled enables and sizes the cache without a restart.
• Setting it back to 0 disables/destroys the cache.
• Concurrent reads during enable/disable are safe (TSAN clean).

Design notes (from PR review)

Suggested during review (https://github.com/10gen/mongo/pull/56406#discussion_r3449791554): unify the cache lifecycle and resize so a single entry point owns the "having cache" <-> "no cache" transitions. Concretely:

• Make the container-level ConcurrentSizedLRUCache::setMaxSize an internal detail rather than something the parameter path calls into across the create/destroy boundary.
• Turn initBlockCache into a general "apply cache size" handler that creates or destroys the cache as disaggBlockCacheSizeBytes (and shard count) crosses 0 – e.g. implemented as resize(0); resize(size) – so startup and runtime go through the same path.

Note: SERVER-129474 instead disables the cache at size 0 by evicting and gating plh_cache_available (so WiredTiger skips the victim-cache path) rather than destroying the cache object; the destroy-on-0 and create-on-enable transitions are the work tracked here.