From 4037e746aa08d24fa42ae3a71925091e72c96c96 Mon Sep 17 00:00:00 2001 From: Daniel Samson <12231216+daniel-samson@users.noreply.github.com> Date: Mon, 10 Aug 2026 19:35:04 +0100 Subject: [PATCH] docs: storage remount-on-replug is bench-pending, not bench-verified MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. --- docs/file-system-development/storage-architecture.md | 2 +- docs/file-system-development/storage-design-rationale.md | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/file-system-development/storage-architecture.md b/docs/file-system-development/storage-architecture.md index c232a72..c1ae20b 100644 --- a/docs/file-system-development/storage-architecture.md +++ b/docs/file-system-development/storage-architecture.md @@ -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; diff --git a/docs/file-system-development/storage-design-rationale.md b/docs/file-system-development/storage-design-rationale.md index 430d7c5..838ae89 100644 --- a/docs/file-system-development/storage-design-rationale.md +++ b/docs/file-system-development/storage-design-rationale.md @@ -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/` 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/` (the kernel