Skip to content

[Discussion] Should aarch64 throw an exception when db.engine=LEVELDB? #6587

@halibobo1205

Description

@halibobo1205

Background

Storage.java:177 currently handles aarch64 by silently falling back to RocksDB:

if (Arch.isArm64()) {
  logger.warn("Arm64 architecture detected, using RocksDB as db engine, ignore config.");
  return ROCKS_DB_ENGINE;
}

config.conf file defaults to db.engine = "LEVELDB" — shared between x86 and aarch64

And the default config for x86 is DEFAULT_DB_ENGINE = "LEVELDB"

Aarch64 does not support LevelDB. As a result, aarch64 nodes running the default config always hit this fallback, rolling back to RocksDB, and print only one warning log.

Problem

checkOrInitEngine provides a helpful error on x86: when the configured engine mismatches the existing data directory, the error message points directly to the cause.

This breaks down on aarch64. Consider a node migrated from x86 (with a LevelDB data directory) to arm64: both the config and the on-disk data are LevelDB, so they appear consistent to checkOrInitEngine. The silent engine switch to RocksDB then causes it to throw:

Cannot open LEVELDB database with ROCKSDB engine

Operators see a database error with no indication that the real cause is an architecture/engine incompatibility. The error chain is broken precisely because the fallback happens before checkOrInitEngine can reason about it correctly.

Two constraints prevent simply changing the defaults:

  • config.conf defaults to db.engine = "LEVELDB" — shared between x86 and aarch64, so this cannot be changed
  • DEFAULT_DB_ENGINE = "LEVELDB" — changing this would affect x86 users

Therefore, it's not possible to simply throw an exception when using aarch64 + LEVELDB; otherwise, all arm64 users using the default configuration will fail to start.

Open for discussion

  • Targeted exception on data directory mismatch — throw a clear "architecture does not support the configured engine" exception only when an existing LevelDB data directory is detected (hooking into or extending checkOrInitEngine logic), while continuing to fall back silently for fresh nodes with no existing data.
  • Other approaches — are there alternative ways to surface a clear error to operators without changing the default config or breaking the happy path?
  • Status quo — is the current behavior acceptable given the constraints?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions