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)
2.6 KiB
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
- clippy -D warnings in cubesys — 4 lints fixed
- cube-bench executed — correctness-gated microbenchmarks
- cubecli extracted — standalone crate
- go live (./check gate) — passes
THIS session: ran all 4 ./check opt-in stages in logical order
-
./check mount — PASS (57 assertions, 0 failed)
- In-memory
--seedmount: full regression suite - Daemon-backed
--socketmount: full regression suite - Durability across daemon restart: verified (record survives kill+restart)
- Cross-user ACLs (root ↔ luulu): verified
- In-memory
-
./check daemon — PASS (3 tests, 0 failed)
cubefs_create_write_reaches_daemondaemon_backend_envelope_roundtripdaemon_backend_put_get_roundtrip- All 3 were
#[ignore]d, now exercised against live cube-server
-
./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
-
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_forspreads across c=0,1,2,3 asigrows past 65536. At scale=200k, c=1 should have 65536 records (not 134464). - Fix: compute expected counts per C bucket from the
coord_formapping (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 -- --checkclean,cargo clippy -p cube-bench -- -D warningsclean, 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.
- Bug found: bench's expected-value math assumed all records beyond c=0 land in c=1, but
Git state
- Working tree:
cube-bench/src/main.rsmodified (the fix above) - Branch:
feat/os-kernel-in-cube - All prior session commits intact (
7b0cf6fis 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
- Commit the cube-bench fix (27 insertions, 5 deletions)
- README/docs sync — reflect cubecli as standalone crate (./check doesn't check docs)
- Spec reading resumption from CUBELinux.txt (~offset 360+) — Package 2 use cases