Verify the controller identity that segments observation history #11

Closed
opened 2026-08-31 10:09:48 +00:00 by xavierk · 1 comment
Owner

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-identity branch and link them from this ticket.

Parent map: [Chart Fenris’s persistent TUI monitoring redesign](https://git.bongbetic.com/xavierk/Fenris/issues/1) ## 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](https://git.bongbetic.com/xavierk/Fenris/src/branch/main/docs/adr/0001-observation-store-sqlite.md)'s segment and migration rules assume about it. Record findings on a `research/controller-identity` branch and link them from this ticket.
xavierk added this to the Wayfinder: Fenris persistent TUI monitoring redesign milestone 2026-08-31 10:09:48 +00:00
xavierk added the wayfinder:research label 2026-08-31 10:09:48 +00:00
xavierk added a new dependency 2026-08-31 11:45:44 +00:00
xavierk self-assigned this 2026-08-31 14:53:22 +00:00
Author
Owner

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.jsonl carries only device + 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 plus sn/mn/fr/subnqn metadata. 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.

## 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.jsonl` carries only `device` + `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 plus `sn`/`mn`/`fr`/`subnqn` metadata. 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](https://git.bongbetic.com/xavierk/Fenris/src/branch/research/controller-identity/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.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Reference: xavierk/Fenris#11