CUBELinux-2andHermes Agent (upstage/solar-pro4:free)
c090233056
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)
51 lines
2.6 KiB
Markdown
51 lines
2.6 KiB
Markdown
# RESUME POINT — HashBackend (HashMap<u32, Vec<u8>>) 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
|