clippy -D warnings flagged implicit_saturating_sub on the c1/c2/c3
expected-count calculations. Replace manual - with saturating_sub so
the lint gate stays clean at any scale.
Co-Authored-By: Hermes Agent (upstage/solar-pro4:free)
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)
ConcurrentStore.inner is now Arc<RwLock<CubeStore>>: all read paths take the
read side, all mutations + checkpoint take the write side. Readers no longer
exclude each other and overlap an active writer (verified by
concurrent_reads_dont_block_on_writer + cube-bench Task 4 section). WAL,
checkpoint, and coordinate encoding are untouched, so durability/replay is
unchanged (.check green).
Honest finding recorded in docs/task4-reader-writer-sharding.md: on this 8-core
host std RwLock removes reader-vs-reader exclusion (correct) but shows no
wall-clock speedup for short reads (cache-line bounce on one shared lock). Real
read-throughput scaling would need sharded/lock-free storage, left as a
follow-up decision rather than invented.
- cube-bench crate: real-code-path throughput/latency over cubestore,
cubecrypt (aes/gcm/chacha/xts), cubecode VM, and cubesys Session.
Every section asserts correctness before timing. Wired into ./check
as an opt-in 'bench' stage.
- cubesys Session: per-command latency histogram + per-C-namespace record
counts, exposed via a new 'stats' command over the live socket.
- Deployed rebuilt cube-server to /home/luulu/.cubelinux/bin and
restarted the system cube.service; verified stats live.
