Cache Priority

Overview

The Elastic Data engine’s object storage provides scalable capacity and cost efficiency, but read I/O latency can vary depending on the data source. Cache Priority ensures selected VDBs receive consistently low‑latency reads by reserving space for them in the block storage cache. This feature does not alter system‑level caching behavior; it simply enforces predictable performance for VDBs that require block‑storage‑level latency.

Note: High Cache Priority should be enabled with discretion, as it allocates block storage cache proportional to the VDB’s referenced capacity. Excessive or uncoordinated use of this feature can reduce the cache available to Normal Cache Priority VDBs, potentially increasing their read latency due to diminished access to block storage caching resources.

How read latency works

Source	Description	Typical latency profile
System memory	Adaptive in‑memory cache	Near‑instantaneous
Block storage cache	Local block-based cache	SSD/NVMe Block‑storage latency
Object storage	Remote cloud/object backend	Higher, more variable “cloud latency”

Cache Priority drives reads toward the Block Storage Cache path for High Cache Priority enabled VDBs so customers experience consistent block‑storage‑like latency.

What Cache Priority does

• Reserves block storage cache capacity per VDB for all blocks referenced by the latest snapshot.

• Warms cache by reading from object storage if needed.

• Keeps reservations sized dynamically as the VDB grows or shrinks (post‑snapshot).

• If total reservations exceed the block storage cache, the system will auto‑disable Cache Priority (set to Normal) on one enabled VDB to restore capacity.

Scope and limitations

• This feature is supported in release 2026.2.0.0. If upgrading to this version or later, the engine must be rebooted for Cache Priority to function properly.

• Management of this feature is supported by the DCT UI or engine’s CLI.

• Not intended as a global performance accelerator for all VDBs.

• Best when most VDBs are fine with default elastic behavior and some VDBs require guaranteed consistency (e.g., weekly high‑priority analytics job).

• Reservation is independent per VDB—even if two VDBs share blocks, each one reserves capacity for its full reference set.

• Up to 90% of the block storage cache may be reserved for Cache Priority

• Enabling High Cache Priority reduces the available capacity in the cache for all Normal priority VDBs.

• The VDB’s High Cache Priority property is not preserved on the target engine during replication. Replicated VDBs revert to the default cache‑priority state.

• After the initial cache warming job completes, the system may still require additional time (typically several minutes per terabyte) to fully migrate all relevant blocks into the block storage cache.

Cache reservation behavior

Even with overlapping data between VDBs, reservations are independent. This guarantees each enabled VDB has space even if another VDB’s feature is turned off later.

Overlap example

Item	Value
VDB1 total referenced data	2 GB
VDB2 total referenced data	2 GB
Shared data	1 GB
Unique total across both	3 GB
Reserved (independent)	4 GB (2 GB + 2 GB)

Why? Each enabled VDB gets a standalone guarantee.

Sizing and capacity planning

• Size block storage cache for non‑priority VDBs’ working set.

• Add extra capacity equal to the sum of reservations for all High Cache Priority enabled VDBs.

• Leave the remaining space unreserved to preserve normal cache behavior.

Sizing table

Input	How to derive	Example
Non‑priority working set	Sum of frequently accessed blocks across standard VDBs	1.5 TB
Priority reservations	Sum of latest‑snapshot sizes per enabled VDB	VDB‑A: 200 GB, VDB‑B: 350 GB → 550 GB
Block storage cache	Non‑priority working set + Priority reservations	2.05 TB
Reservation cap	A maximum of 90% of block storage cache may be used for priority reservations	1.845 TB

Workflows

Enable Cache Priority during provisioning

1. Initiate provisioning with Cache Priority set to High.

2. The system computes the required reservation based on the VDB’s referenced capacity.

3. The system verifies that sufficient block storage cache is available.

4. If capacity is adequate, the system begins cache warming by preloading referenced blocks.

5. Provision completes after cache warming finishes.

Enable Cache Priority after provisioning

1. Set Cache Priority to High on an existing VDB.

2. The system calculates the reservation requirements and checks available block storage cache.

3. If space is sufficient, cache warming begins in the background.

4. The VDB remains fully accessible to the target host throughout the warming process.

Disable Cache Priority (per VDB)

1. Set Cache Priority from High to Normal on an existing VDB.

2. Unreserve the space.

3. Data remains in cache but follows normal eviction policy.

Automatic capacity protection

If cumulative reservations grow beyond capacity, the system auto‑sets Cache Priority to the default setting of Normal on a random enabled VDB to restore health.

Operational Behavior & Error Handling

Event	System behavior	Operator action
Enable requested but insufficient space	Operation fails with required vs available sizes	Increase block storage cache, disable feature on other VDB(s), or reduce set of enabled VDBs.
VDB size changes (post‑snapshot)	Reservation grows/shrinks with latest snapshot	Ensure snapshots run at appropriate cadence.
Reservations exceed capacity	Random VDB with High Priority Cache enabled has the feature set to the default of Normal	Review capacity, sizing assumptions, and enabled set.
Feature disabled on VDB	Reservation released; data remains cached until evicted	None

Snapshot Dependencies

• Reservation size is calculated from the latest snapshot.

• Data inserted into block storage cache is from that snapshot.

• VDB changes (growth/shrink/content) are recognized after a new snapshot.

• For empty vFiles, initial reservation is minimal. After adding data, create a snapshot so the reservation grows and data remains resident in block storage cache.