JindoFileSystem (JindoFS) cache mode stores data as objects in Object Storage Service (OSS) and caches both data and metadata in the local E-MapReduce (EMR) cluster. This reduces latency for repeated reads and writes — your existing OSS data is accessible without migration.
How it works
When cache mode is enabled:
Data files are stored as objects in OSS.
Data and metadata are cached in the local cluster based on the requirements for accessing these files, accelerating subsequent reads and writes.
JindoFS remains compatible with the OSS client, OssFileSystem, and other OSS-compatible applications.
Use cases
Cache mode is a good fit when you:
Access existing OSS data — JindoFS reads from your current OSS buckets without requiring data migration or format conversion.
Run repeated reads on the same dataset — local caching reduces round-trips to OSS for hot data.
Need OSS compatibility — cache mode preserves original OSS semantics, so applications that communicate directly with OSS continue to work alongside JindoFS.
Configure JindoFS in cache mode
Configure all JindoFS parameters in Bigboot by updating the ConfigMap.
Figure 1. Update a ConfigMap 
Figure 2. Add a configuration item 
The parameters highlighted in red in the figures are required. The following example uses a namespace named test.| Parameter | Description | Example |
|---|---|---|
jfs.namespaces | Namespaces supported by JindoFS. Separate multiple namespaces with commas. | test |
jfs.namespaces.test.uri | Storage backend for the test namespace. Set this to an OSS bucket or a directory within a bucket. When set to a directory, that directory becomes the root for all reads and writes in the namespace. Setting it to the bucket root keeps the path consistent with OSS. | oss://oss-bucket/ |
jfs.namespaces.test.mode | Storage mode. Set to cache to enable cache mode. | cache |
jfs.namespaces.test.oss.access.key | AccessKey ID used to access the OSS bucket. We recommend that you store data in an OSS bucket that is in the same region and under the same account as your EMR cluster. This ensures high performance and stability. In this case, you do not need to configure the AccessKey ID and AccessKey secret because the OSS bucket allows password-free access from the EMR cluster. | xxxx |
jfs.namespaces.test.oss.access.secret | AccessKey secret used to access the OSS bucket. Leave blank if password-free access applies. | — |
After updating the ConfigMap, save and deploy the JindoFS configuration. Then restart Namespace Service in SmartData to apply the changes.
Configure a metadata synchronization policy
When data already exists in OSS before you configure JindoFS, its metadata must be synchronized into JindoFS before it becomes accessible. Data is cached in the local cluster each time data is accessed; metadata synchronization is controlled separately.
JindoFS provides two metadata synchronization policies.
namespace.sync.loadtypetakes effect only whennamespace.sync.intervalis not set.
Interval policy
Use namespace.sync.interval to control how often JindoFS syncs metadata from OSS.
| Value | Behavior |
|---|---|
-1 (default) | JindoFS does not sync metadata from OSS. |
0 | JindoFS syncs metadata from OSS on every access. |
N (seconds, where N > 0) | JindoFS syncs metadata from OSS every N seconds. For example, setting 5 syncs every 5 seconds. |
Loading policy
Use namespace.sync.loadtype when you want to control the initial sync behavior without periodic syncing.
| Value | Behavior |
|---|---|
once (default) | JindoFS syncs metadata from OSS only once. |
never | JindoFS never syncs metadata from OSS. |
always | JindoFS syncs metadata from OSS on every access. |