Execution — How to Build and Run
Quick start (per language)
# Rust
cd src/rust
cargo build --release
cargo test --release
./target/release/walbench --help
# Go
cd src/go
go test ./...
go build -o bin/walbench ./cmd/walbench
./bin/walbench --help
# C++
cd src/cpp
cmake -S . -B build && cmake --build build
ctest --test-dir build
./build/walbench --help
CLI: walbench
A single binary per language exercising the WAL.
| Subcommand | Args | What it does |
|---|---|---|
append PATH N [SIZE] | path, count, payload bytes (default 64) | Appends N records of SIZE bytes; reports bytes/sec |
append-sync PATH N [SIZE] | same | Same as append but sync() after each record |
read PATH | path | Replays the log, prints len(crc=…) ok per record, then OK n=… bytes=… |
corrupt PATH OFFSET BYTE | path, offset, byte value | Overwrites one byte in place — for testing tail tolerance |
bench-group PATH N BATCH | path, total records, batch size | Group-commit benchmark: sync once per BATCH records |
Library API
Same shape in all three languages.
Wal::open(path) -> Wal // creates or opens for append, scans to EOF
Wal::append(payload) -> u64 offset // record start offset in file
Wal::sync() -> () // fdatasync (or fsync) the file
Wal::len() -> u64 // bytes on disk (post-append, post-sync)
Wal::close() -> () // implicit on Drop in Rust / RAII in C++
Wal::iter(path) -> iterator<Vec<u8>> // streams records; stops at first bad/short
open scans forward at startup to (a) find true EOF after a partial-write recovery and (b) optionally truncate the file to that position so the next append doesn't append after a known-bad tail. We do truncate in this implementation — the alternative (leave the bad tail in place) makes file size useless and complicates len().
Verifying
./scripts/verify.sh # invariants per implementation
./scripts/cross_test.sh # write in lang A, read in lang B, all six pairs