# VERIFICATION: cubefs FUSE view <-> cube-server daemon durability (REVISED 2026-08-13)

Hard record for later review. Date: 2026-08-13 (session after restart).

## Critical correction to the prior version of this file
The earlier "proof" in this file was measured against `CubeFs` DIRECTLY
(`cubefs_daemon_smoke` test calling `fs.create`+`fs.write` on a `CubeFs<DaemonBackend>`),
NOT against the actual `cubefs-mount --socket` FUSE binary. The FUSE binary
(`cubefs-mount`) requires `--features mount` to build, and at that time it did
NOT compile: `CubeFs<B>` is generic, so the `--socket` (DaemonBackend) and
default (HashBackend) arms were incompatible types (E0308). The build was
silently failing, so the running `cubefs-mount` was the IN-MEMORY build — which
is why `--socket` was ignored and every FUSE write went to RAM and never reached
the daemon (rawget/rawkeys returned none / 0 keys, WAL stayed 0 bytes). The
prior "proof" therefore did NOT verify the FUSE mount.

## The actual bug that blocked durable FUSE (now FIXED)
- `cubefs/src/bin/cubefs_mount.rs`: the `match &socket` produced
  `CubeFs<DaemonBackend>` vs `CubeFs<HashBackend>` — incompatible; `--features mount`
  failed to compile (E0308), so the durable mount was never shippable.
- Fix: type-erase the backend. Added `impl CubeBackend for Box<dyn CubeBackend +
  Send + Sync>` (forwards to inner) in `cubestore/src/lib.rs`, and changed the
  mount to build `CubeFs<Box<dyn CubeBackend + Send + Sync>>` via
  `Box::new(DaemonBackend::new(p))` / `Box::new(HashBackend::new())`. Both arms
  are now the same concrete type; `--features mount` compiles.
- This keeps `cubefs` free of a `cubesys` dependency (DaemonBackend duplicates
  the framing locally), so the dependency graph stays acyclic.

## Proof the FUSE mount reaches the daemon AND survives a crash (REAL, this run)
Harness: `bash /tmp/verify_cubefs_daemon_host.sh` (daemon + one mount, both on
the same socket, then `kill -9` daemon and relaunch).

1. `mkdir -p /tmp/verify/mnt/c012/z003/y004`
2. `echo cubefs-e2e-proof-<ts> > /tmp/verify/mnt/c012/z003/y004/x007`
3. FUSE read-back returns `cubefs-e2e-proof-<ts>` (write visible through FUSE).
4. Daemon `rawget 12 3 4 7` -> `ok: <record hex>`; `rawkeys` -> `ok: 5 keys`
   (volume meta + the new record landed in the daemon store).
5. `cube-store.json.wal` grew to **956 bytes** (durable WAL written).
6. `kill -9` the daemon, relaunch with the same `--store`.
7. Post-crash `rawget 12 3 4 7` returns the SAME record bytes; post-crash FUSE
   read-back returns `cubefs-e2e-proof-<ts>`. **Survived the daemon crash.**

Decoded body of the rawget record: `cubefs-e2e-proof-1786613763` — byte-exact
match to what was written through the FUSE mount.

## Conclusion
cubefs is now a genuine FUSE view of the running `cube-server` daemon's durable
store, and a FUSE write lands in the daemon WAL and survives a daemon restart.
The "cubefs as boot-time data root" integration is functionally proven on the
host (shared code path as the VM). Next: repeat the same single-daemon +
single-mount e2e INSIDE the VM to confirm the deployed artifact, then wire
`--socket` into the VM's `cubefs.service` (currently it mounts without
`--socket`, i.e. in-memory — that is why the VM FUSE looked like it worked but
never persisted to the daemon).

## Test files
- cubefs/tests/cubefs_daemon_smoke.rs  (CubeFs+DaemonBackend, needs live daemon via CUBE_SOCK)
- cubefs/tests/daemon_backend_smoke.rs  (DaemonBackend put/get/keys, needs live daemon)
- /tmp/verify_cubefs_daemon_host.sh  (full FUSE mount e2e on host)