Verify the controller identity that segments observation history #11
Notifications
Due Date
No due date set.
Blocks
#13 Define cross-cutting acceptance criteria
xavierk/Fenris
Reference: xavierk/Fenris#11
Reference in New Issue
Block a user
Parent map: Chart Fenris’s persistent TUI monitoring redesign
Question
Which controller-identity key should controller segments record so that a drive replacement quarantines prior observation history while firmware quirks or counter resets on the same drive do not? Verify the stability and availability semantics of candidate NVMe identifiers (model + serial number, NGUID, EUI-64, subsystem NQN, or a composite) across reboots, namespace changes, and drive swaps, how the collector obtains the chosen key via libnvme, and what ADR 0001's segment and migration rules assume about it. Record findings on a
research/controller-identitybranch and link them from this ticket.Resolution
The controller-segment identity key is the normalized, kernel-exposed subsystem NQN (via libnvme, whose attribute getters already strip padding), with a fallback ladder: device SUBNQN → the kernel's synthesized composite
nqn.2014.08.org.nvmexpress:{vid}{ssvid}{sn}{mn}(reproduced byte-for-byte) →model|serial. NQNs compare as binary strings — trailing spaces stripped, no case folding. FR (firmware revision) is recorded as segment metadata and never enters the key; NGUID/EUI-64 are rejected (namespace-scoped, optional, reusable after namespace re-creation); CNTLID is rejected (unique only within a subsystem).Why it holds the ticket's asymmetry: real NQNs are unique per NVM subsystem and permanent for its lifetime (Base Spec 2.0e §4.5), and kernel-generated NQNs embed serial + model, so a replacement — even by an identical model — changes the key, while a firmware update leaves SN/MN/SUBNQN untouched. Counter resets and firmware quirks stay on ADR 0001's independent DUW-monotonic axis. A same-model, same-serial swap is unobservable by any identifier; the DUW-decrease rule catches it as a boundary.
ADR 0001 consequences: legacy
history.jsonlcarries onlydevice+model, so migration imports legacy rows under a labeled model-scoped legacy identity; the first new-version collection run opens a new segment recording the full key plussn/mn/fr/subnqnmetadata. Normalization must be specified once and applied at write time — smartctl, nvme-cli, and libnvme deliver differently-trimmed values, so a collector change without a fixed rule could split a drive's own history.Full findings with per-claim primary citations (Base Spec 2.0e, libnvme man pages and source, kernel sysfs docs and nvme core sources, plus an empirical sysfs check on this host's Micron 2400): docs/research/controller-identity.md
Surfaced follow-ups (now ticketed): the collector's acquisition-path choice, segment metadata extras (
vid/ssvid/cntlid), and whether degraded identity degrades projection confidence.