daniel/danos
1
0
Fork 0
Code Issues 4 Pull Requests Actions Packages Projects 1 Releases Wiki Activity

docs: storage remount-on-replug is bench-pending, not bench-verified

Browse Source 
The physical unplug/replug remount was never actually bench-run — the claim was
carried over from S3. QEMU cannot re-present a usb-storage device_add, so this
path is only reachable on real hardware. Correct both docs to say bench-pending,
keeping the honest distinction: the re-adopt+remount CODE PATH is QEMU-proven by
the driver-crash rebuild; only the physical-replug end-to-end awaits a bench pass.
This commit is contained in:
Daniel Samson
2026-08-10 19:35:04 +01:00
parent 4dfb5012c0
commit 4037e746aa
2 changed files with 4 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/file-system-development/storage-architecture.md
+1 -1
View File
@@ -28,7 +28,7 @@
> crashes while its device stays present (a channel-liveness `geometry()` probe
> reaps the volume and rebuilds it on the restarted driver's fresh channel). The
> re-adopt-and-remount path is QEMU-proven by the driver-crash rebuild; a physical
> unplug/replug exercises the same path and is bench-verified (QEMU cannot
> unplug/replug exercises the same path but is bench-pending (QEMU cannot
> re-present a usb-storage `device_add`). **Still pending**: the `filesystem UUID`
> rung (ext-family superblocks, which need such an engine); and arbitration when
> two volumes both resolve the boot markers (S3 mounts both and logs each claim;
docs/file-system-development/storage-design-rationale.md
+3 -2
View File
@@ -251,8 +251,9 @@ matrix-proven shape; genuinely open.
whether USB port, hub depth, SATA port, or a stick that left as USB and
returned in a SATA dock; **replug remounts at the same path** (the id-path is
content-derived, so a volume returns to `/volumes/<id>` wherever it reappears;
remount-on-replug end-to-end is bench-verified, not QEMU-tested, because QEMU
can't re-present the boot-controller device); **the boot volume** is the volume
the re-adopt+remount code path is QEMU-proven by the driver-crash rebuild, but
remount on a *physical* replug end-to-end is bench-pending, not QEMU-testable,
because QEMU can't re-present the boot-controller device); **the boot volume** is the volume
that resolves `/system/configuration` on its own media, findable on any port or
partition; and **duplicate identity is a known S4 gap** — two cloned sticks
share one content id, so today they collide on `/volumes/<id>` (the kernel