Files
cubelinux-2/RESUME-20260820-hashmap.md
T
CUBELinux-2andHermes Agent (upstage/solar-pro4:free) c090233056 bench(cube-bench): fix scan_prefix expected-value math for scale > 65536
coord_for spreads records across C=0,1,2,3 as i grows past 65536,
but the bench assumed everything beyond c=0 landed in c=1. At
scale=200k this asserted (got 65536, expected 134464). Fix: compute
per-bucket expected counts from the coord_for mapping and extend the
total-coverage assertion to include c=2 and c=3.

Verified: fmt clean, clippy -D clean, 100k + 200k both pass.

Co-Authored-By: Hermes Agent (upstage/solar-pro4:free)
2026-08-20 18:56:20 -04:00

2.6 KiB

RESUME POINT — HashBackend (HashMap<u32, Vec>) work, 2026-08-20 → 2026-08-21

WHAT WAS DONE THIS SESSION (continuation)

Prior session's 4 tasks — all closed and verified

  1. clippy -D warnings in cubesys — 4 lints fixed
  2. cube-bench executed — correctness-gated microbenchmarks
  3. cubecli extracted — standalone crate
  4. go live (./check gate) — passes

THIS session: ran all 4 ./check opt-in stages in logical order

  1. ./check mount — PASS (57 assertions, 0 failed)

    • In-memory --seed mount: full regression suite
    • Daemon-backed --socket mount: full regression suite
    • Durability across daemon restart: verified (record survives kill+restart)
    • Cross-user ACLs (root ↔ luulu): verified
  2. ./check daemon — PASS (3 tests, 0 failed)

    • cubefs_create_write_reaches_daemon
    • daemon_backend_envelope_roundtrip
    • daemon_backend_put_get_roundtrip
    • All 3 were #[ignore]d, now exercised against live cube-server
  3. ./check stress — PASS (~150s, 57075 pairs driven)

    • Daemon alive throughout, ~380 prog+run pairs/s sustained
    • 156 records in C=77 namespace (command dedup by coordinate)
    • No crashes, no latency spikes
  4. cube-bench at scale 200k — FAILED initially, then FIXED and PASS

    • Bug found: bench's expected-value math assumed all records beyond c=0 land in c=1, but coord_for spreads across c=0,1,2,3 as i grows past 65536. At scale=200k, c=1 should have 65536 records (not 134464).
    • Fix: compute expected counts per C bucket from the coord_for mapping (c=0: min(n, 65536); c=1: next 65536; c=2: next 65536; c=3: remainder). Added expected_c2 + expected_c3 to the total-coverage assertion.
    • Verified: cargo fmt --all -- --check clean, cargo clippy -p cube-bench -- -D warnings clean, 100k + 200k both pass.
    • Numbers at 200k (release): put_raw 236ns/op, get_raw 109ns/op, scan_prefix 12.4ms for 65536 coords, ~4237k put/s, crypto ~1.4-2.6μs/seal, VM 276ns entry / 142ns leaf, session 1.4μs prog / 2.6μs run.

Git state

  • Working tree: cube-bench/src/main.rs modified (the fix above)
  • Branch: feat/os-kernel-in-cube
  • All prior session commits intact (7b0cf6f is HEAD)

CURRENT STATE

  • Branch: feat/os-kernel-in-cube
  • cube-bench at 200k: fixed + verified (fmt + clippy + 100k + 200k all pass)
  • ./check mount/daemon/stress: all green
  • cubecli: standalone crate, functionally identical

NEXT STEPS

  1. Commit the cube-bench fix (27 insertions, 5 deletions)
  2. README/docs sync — reflect cubecli as standalone crate (./check doesn't check docs)
  3. Spec reading resumption from CUBELinux.txt (~offset 360+) — Package 2 use cases