Skip to content

Owned account writes append a new copy even when the live slot fits #100

Description

@Dodecahedr0x

Problem

PersistedStore::insert allocates a fresh exact-fit span for every owned account write, even a same-size update of an account that already has a live slot. A workload that grows a single account incrementally appends a full copy of the account image on every write, so the mmap cursor advances by the whole account size each time. In the sealed-bid 41k-bidder run, each record_bid grows the shared auction tree by ~64 bytes; by the end of the drain every write copies a multi-megabyte image, storage balloons by gigabytes, and write latency grows with the account.

Reproduction

Prerequisites: rustup, the Solana CLI, Anchor CLI 1.x, Node 20+ with pnpm, and mb-stack (npm i -g @magicblock-labs/ephemeral-validator@0.14.10).

  1. Clone the test workload and the validator (validator fix-stack tip) side by side — the workload's test harness builds and launches the sibling validator with cargo run automatically:
git clone -b dode/test-undelegation https://github.com/magicblock-labs/sealed-bid-metadao
git clone -b dode/committor-backlog-ordering https://github.com/magicblock-labs/magicblock-validator
  1. Point the validator at the engine revision missing this fix (dev, the base of fix: adb slot reuse #103):
sed -i '' 's/ec741da47eca2f43f5797dde2530640ecb12aa39/cd021975429a9504f35d52dc9d5b0393a3c3e302/g' magicblock-validator/Cargo.toml
# Linux: sed -i (without '')
  1. Run the oversized-result lifecycle test (41,000 bid tickets delegated, recorded, and undelegated in one burst):
cd sealed-bid-metadao
pnpm install
MOCHA_GREP="grows the published result" pnpm test:local
  1. Observe: the accountsdb directory under the ephemeral validator's ledger (/tmp/sealed-bid-magicblock.*/) grows far past the logical account sizes while tickets drain, and drain throughput degrades as the auction tree grows. At unit level, test_incremental_growth_reuses_slack_span in accountsdb/src/tests.rs (added with the fix) fails at dev: 2,000 incremental +64-byte resizes advance the storage cursor by 2,000 exact-fit copies instead of a few page-aligned spans.

Restoring rev ec741da47eca2f43f5797dde2530640ecb12aa39 (this fix applied, #103) removes the growth.

Expected

A write whose payload still fits the live span overwrites it in place. A small resize lands in a page-aligned slack span so incremental growth reuses storage instead of appending a copy per write.

Context

accountsdb/src/store/mod.rs, PersistedStore::insert, dev @ cd02197 (0.3.1).

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions