[Bug] RocksDB table option setters are ineffective in 4.8.2.1 #6939

Bug Description

In GreatVoyage-v4.8.2.1, RocksDbSettings.getOptionsByDbName() passes a newly created BlockBasedTableConfig to Options.setTableFormatConfig() before applying the table-level setters.

setTableFormatConfig() creates and attaches the native RocksDB table factory immediately. The subsequent setters only modify the Java BlockBasedTableConfig object and do not update the native table factory that was already created.

Affected code:

As a result, the configured block size, shared block cache, index/filter caching, L0 index/filter pinning, and Bloom filter are not reflected in native RocksDB. The Java configuration and startup logging therefore suggest behavior that the native database does not use.

Environment

Network

Mainnet

Software Versions

OS: Amazon Linux on AWS c6g.4xlarge (ARM64)
JVM: OpenJDK 17
Git Commit: f8b05d40abc949fa588ab64d8fd8fd82845ebeed
Version: 4.8.2.1
Code: 18825

Configuration

The replay used:

• A snapshot at block height 83,835,006
• A 500-block input
• A gp3 volume limited to 7,500 IOPS
• The shipped storage.dbSettings.blocksize = 64

The affected release uses RocksDB 9.7.4 on ARM64 and RocksDB 5.15.10 on x86_64.

Expected Behavior

RocksDB table settings exposed through java-tron configuration and applied by RocksDbSettings should be reflected in the native table factory and persisted OPTIONS-* configuration.

Alternatively, settings intentionally retained only for compatibility should be clearly documented as inactive and should not be applied through ineffective setters.

Actual Behavior

The table setters execute after native table-factory creation and do not affect the native OPTIONS-* configuration.

For the tested ARM64 build, the effective native table settings remain:

The x86_64 build uses RocksDB 5.15.10, whose internal default block cache is 8 MiB.

In particular:

• The shipped 64 KiB blocksize does not change the native 4 KiB block_size.
• The shared 1 GiB cache is not attached.
• Index/filter caching and L0 pinning remain disabled.
• The configured 10-bit Bloom filter is not installed.

Changing only the call order is not a safe compatibility fix because it activates several previously inactive settings simultaneously.

In the fixed 500-block replay, the following multi-variable results were observed:

The direct-activation runs reached approximately 7,500 IOPS. Average DB Get latency increased from approximately 0.205 ms to 0.325 ms and 0.420 ms.

These are multi-variable results and must not be attributed to any single RocksDB option.

Frequency

• Always (100%)
• Frequently (>50%)
• Sometimes (10-50%)
• Rarely (<10%)

Steps to Reproduce

1. Use the RocksDbSettings.getOptionsByDbName() implementation from GreatVoyage-v4.8.2.1.
2. Open a fresh RocksDB database with the returned Options.
3. Inspect the generated OPTIONS-* file.
4. Compare the native table settings with the setters invoked after setTableFormatConfig().

The native configuration contains values such as:

block_size=4096
cache_index_and_filter_blocks=false
pin_l0_filter_and_index_blocks_in_cache=false
filter_policy=nullptr
whole_key_filtering=true
block_restart_interval=16

These values do not reflect the later Java table setters.

Logs and Error Messages

No exception is thrown. The failure is the mismatch between the Java configuration and the native RocksDB OPTIONS-* output.

Additional Context (Optional)

Possible Solution

Preserve the effective behavior used by existing nodes rather than moving setTableFormatConfig() after the setters:

• Retain blocksize in the configuration and Java API for compatibility, but document that it is not currently applied to native table options.
• Remove the ineffective table setter sequence without activating those settings.
• Retain existing effective Options-level settings.
• Verify the behavior using a fresh temporary database and its native OPTIONS-* file.
• Evaluate block size, Bloom filters, shared-cache capacity, index/filter caching, and L0 pinning independently before enabling a new table profile.

Acceptance criteria:

• blocksize and its existing API remain compatible and are documented as inactive.
• Ineffective table setters are removed without activating them through reordering.
• A fresh database retains the intended compatibility behavior: 4 KiB blocks, no Bloom filter, and no L0 index/filter pinning.
• Configuration tests, native Options tests, and Checkstyle pass.