Why should this feature exist?
What are the use-cases?
Implementation
We will have two dirty KVs, where
The first one is read-only KV, which is under committing to DB (can be nil if it is committed)
The second is rw KV
When the second KV is full and the first KV is nil, then we will move the second KV to the first KV, then commit the second KV in a background thread. This should allow the blockchain to continue to work since rw from EVM can be still handled. This also reduces the node hang during compaction.
The only way that the blockchain's operation is blocked when the first KV is full, while the second KV is still being committed, which implies the node's performance cannot meet the performance requirement.
Rationale
Why should this feature exist? What are the use-cases?
Implementation
We will have two dirty KVs, where
When the second KV is full and the first KV is nil, then we will move the second KV to the first KV, then commit the second KV in a background thread. This should allow the blockchain to continue to work since rw from EVM can be still handled. This also reduces the node hang during compaction.
The only way that the blockchain's operation is blocked when the first KV is full, while the second KV is still being committed, which implies the node's performance cannot meet the performance requirement.