繁體中文 00.01.After a device resets, how can we tell what happened before it? Persistent Event Log retains significant events in a common format, including health snapshots, firmware updates, power events, namespace changes and configuration. This report first explains consistent retrieval, then connects time, target, parameters and outcomes while respecting what the evidence can establish.Persistent Event LogThe LID 0Dh history of significant subsystem events.namespaceNamespace, a formatted quantity of non-volatile memory accessed by a host through a controller. The main ideas 01What the history preserves01-01Support, storage limits and actual contents are distinct. Understand subsystem scope, persistence and possible omissions before treating the...
read more
NVMe Persistent Event Log: Retrieval, Event Formats, and Historical Interpretation
00.01.After a device resets, how can we tell what happened before it? Persistent Event Log retains significant events in a common format, including health snapshots, firmware updates, power events, namespace changes and configuration. This report first explains consistent retrieval, then connects time, target, parameters and outcomes while respecting what the evidence can establish.
- Persistent Event Log
- The LID 0Dh history of significant subsystem events.
- namespace
- Namespace, a formatted quantity of non-volatile memory accessed by a host through a controller.
The main ideas
What the history preserves
01-01Support, storage limits and actual contents are distinct. Understand subsystem scope, persistence and possible omissions before treating the log as a complete trace.
The retrieval lifecycle
02-01Establish context → read header → retrieve chunks → compare generation → release. Separate newly logged events from the fixed set being retrieved.
- context
- The report selection and tracking state used by this retrieval; later events are excluded.
- header
- The leading descriptive structure containing the type, size, revision and related interpretation data.
Three layers of data
03-01The log header describes the report, the common event header describes one record, and ED contains type-specific data. Lengths and revisions belong to different layers.
- ED
- Event Data, the type-specific content after the common header and optional vendor information.
Build justified relationships
04-01Group health, time/reset, storage changes, sanitization, hardware and configuration. Combine target, action and result rather than inferring success from one name, percentage or timestamp.
Connecting Base and NVM
05-01Base provides the Namespace Change envelope; NVM specifies FLBAS/DPS. Vendor extensions complete the picture while unknown content remains bounded and preserved.
- FLBAS
- Formatted LBA Size, encoding a format index and metadata transfer mode, not a literal byte size.
- DPS
- End-to-end Data Protection Type Settings, selecting protection-information type and position.
- NVM
- Non-Volatile Memory, memory that retains data without power.
00.02.Assumes operating systems, computer organization and basic SSD concepts. Controllers A/B, namespace7 and numeric examples are illustrative, not assumed hardware configurations.
00.03.The Chinese tutorial develops the reasoning and field examples; the equivalent posts establish a global view and then provide a forward Spec route. Other references supply only fields needed to interpret these events.
Connecting the main ideas
00.04.Follow five questions: what can this device log, which report am I reading, where does each record begin, what does its payload mean, and what conclusion does the evidence support?
00.05.Use a lifecycle diagram for contexts, a byte-layout diagram for lengths, and time/target comparisons for events. Group related fields and explain shared structures once, with a distinct example for each source figure.
01 Distinguish history, current state and completeness
01.01.Persistent Event Log (PEL, LID 0Dh) retains significant NVM subsystem events across power cycles and resets. It is not a trace of every I/O or a guaranteed complete history: vendors define capacity, per-type limits, frequency suppression and eviction, and Sanitize may remove or modify records.
- NVM subsystem
- NVM subsystem, the NVMe system boundary containing controllers, ports, namespaces, and non-volatile storage resources.
- I/O
- Input/Output, the class of data operations performed on a namespace.
- LID
- Log Page Identifier: selects the type of log page to read.
- PEL
- Persistent Event Log, the history examined in this report.
Sources: Base 2.4 §5.2.13.1.14
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, printed pages 244-245, PDF pages 270-271
02 Use a reporting context to retrieve one consistent report
- GNUM
- Generation Number, compared before and after multipart retrieval.
- Host
- The system running the operating system and issuing NVMe commands.
- RCE
- Reporting Context Exists, indicating a context already present when processing began.
02.01.A reporting context fixes the event set for this report; later events are still logged but excluded from that context. ACT=1 establishes and reads, failing if a context exists; ACT=0 reads an existing context, failing if absent; ACT=2 releases and tolerates absence. Supported ACT=3 establishes or reuses a context and always returns the 512-byte header at offset zero.
- reporting context
- The event selection, locations and tracking information for one report, distinct from the underlying persistent history.
- offset
- A displacement from the specified origin, in bytes from zero unless stated otherwise.
- ACT
- Action, selecting PEL read, establish or release operations.
Sources: Base 2.4 §5.2.13.1.14
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, printed pages 245-246,251, PDF pages 271-272,277
03 Walk from the header to each event boundary
- VSIL
- Vendor Specific Information Length in bytes.
- EHL
- Event Header Length, excluding the first three bytes.
- VSI
- Vendor Specific Information, the optional addition in the common event format.
- EL
- Event Length, counting VSI and ED after the event header.
03.01.The log header occupies LHL+20 bytes and an event header occupies EHL+3 bytes. EL already includes the VSIL vendor-information bytes: total record size is EHL+3+EL and ED size is EL−VSIL. LREV describes the outer format; ET and ETR select the payload format.
- LREV
- Log Revision, the outer log and common event-header revision.
- ETR
- Event Type Revision, the type-specific payload revision.
- LHL
- Log Header Length, excluding the first20 bytes.
- ET
- Event Type, the record’s type code.
Sources: Base 2.4 §5.2.13.1.14
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, printed pages 247-251, PDF pages 273-277
04 Interpret health snapshots, telemetry references and temperature events
| Event | Preserved data | Question answered |
|---|---|---|
| 01h SMART | 512-byte health snapshot | Historical health and counters |
| 0Ch Telemetry | First512-byte diagnostic header | Which capture and which boundaries |
| 0Dh Thermal | Threshold code and relative difference | Which crossing or thermal-control change |
- Telemetry
- Diagnostic internal-state data; the event here preserves only its header.
- snapshot
- A copy captured at one time, distinct from later current state.
04.01.ET=01h stores a 512-byte SMART snapshot at intervals no greater than 24 power-on hours. ET=0Ch may record the first 512 bytes of newly created telemetry, not its complete diagnostic data. ET=0Dh records thermal-threshold events; OTMP is a Kelvin difference from a threshold, not an absolute temperature. These are historical observations.
Sources: Base 2.4 §5.2.13.1.14.2.1; 5.2.13.1.14.2.12; 5.2.13.1.14.2.13
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.1; 5.2.13.1.14.2.12; 5.2.13.1.14.2.13, printed pages 252,264-266, PDF pages 278,290-292
05 Connect firmware, timestamps and reset records
05.01.ET02 is logged when Firmware Commit completes and does not by itself prove activation. ET04 records completed power-on/reset with the effective FREV and per-controller information. ET03 stores the previous timestamp in PTSTP and the new timestamp in the event header ETSTP. Timestamps may originate at reset, be host-set, or include periods when counting stopped.
- controller
- Controller, the entity that implements the NVMe interface, fetches commands, and reports completions.
- ETSTP
- Event Timestamp, the event time recorded in the common header.
Sources: Base 2.4 §5.2.13.1.14.2.2; 5.2.13.1.14.2.3; 5.2.13.1.14.2.4; 5.2.30.1.8
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.2; 5.2.13.1.14.2.3; 5.2.13.1.14.2.4; 5.2.30.1.8, printed pages 252-254,470-471, PDF pages 278-280,496-497
06 Connect namespace changes to NVM format fields
- metadata
- Additional information stored with a logical block; it can contain protection information or serve other purposes.
- PI
- Protection Information used to check data integrity and associated information.
06.01.ET06 records successful Namespace Management commands. Base Figure247 defines the payload and field origins; NVM Figure112 specializes byte32 FLBAS and byte33 DPS: host-specified values for creation, Identify values for single-namespace deletion, and reserved fields for deletion of all namespaces.
Sources: NVM Command Set 1.3 §4.1.4.4
Source: NVME-NVM-CS-1.3, Rev. 1.3, §4.1.4.4, printed pages 76-77, PDF pages 76-77
07 Separate sanitize start, completion and media verification
| Record | Established fact | Not yet established |
|---|---|---|
| 09h Start | Entered processing; parameters and NSID saved | Operation completed |
| 0Eh Media Verification | Entered verification; no ED | Successful completion or NSID in ED |
| 0Ah Completion + SOS3 | Entered failure state | FFFFh proves success |
| 0Ah Completion + SOS1 | This operation succeeded | No data can ever be written afterward |
- NSID
- Namespace Identifier, a controller-visible numeric handle for a namespace; the identifier is not the namespace object itself.
07.01.ET09 records entry into sanitize processing; ET0A records entry into Idle or a failure state. Successful command completion is not completion of the long-running operation. ET0E marks entry into Media Verification with ETR=1 and EL=0, carrying no ED. Start/completion NSID identifies the target; FFFFFFFFh means the subsystem.
Sources: Base 2.4 §5.2.13.1.14.2.9; 5.2.13.1.14.2.10; 5.2.13.1.14.2.14
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.9; 5.2.13.1.14.2.10; 5.2.13.1.14.2.14, printed pages 261-262,266, PDF pages 287-288,292
08 Select the hardware-error code before its additional format
08.01.In ET05, NSHEEC selects the hardware-error kind and thereby the AHEI layout and length. Codes01h–03h carry PCIe error information, 08h unexpected-power-loss information, and 0Bh controller-ready timeout information; some kinds have no AHEI. Vendors select supported subtypes, so one fixed layout cannot decode every ET05.
- NSHEEC
- NVM Subsystem Hardware Error Event Code, selecting an ET05 subtype.
- AHEI
- Additional Hardware Error Information, whose format depends on the error subtype.
- PCIe
- PCI Express, the transport and device interconnect used by an NVMe memory-based controller.
Sources: Base 2.4 §5.2.13.1.14.2.5
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.5, printed pages 254-258, PDF pages 280-284
09 How feature events preserve commands and data
- SFEL
- Set Feature Event Layout, locating command words, buffer data and completion DW0.
- FID
- Feature Identifier: selects the Feature to read or configure.
09.01.ET0B must be logged for successful value-changing Set Features when logging is supported; successful same-value requests may be logged. Figure252 O/P/NR describes logging requirements for a feature/controller type, not feature support. SFEL locates consecutive command Dwords, an optional data buffer and optional completion DW0.
- P
- Phase Tag, the toggling bit used by the host to decide whether a CQ slot contains a new completion.
Sources: Base 2.4 §5.2.13.1.14.2.11
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.11, printed pages 262-264, PDF pages 288-290
10 Read identifier mappings and vendor extensions within their boundaries
10.01.ET10 records creation, deletion or entity changes of an Exported NVM Subsystem; OTYP determines whether EEID/UEID identify a namespace, controller, port or another object. ETDE ED contains vendor descriptors, each 6+VSEDL bytes and interpreted by VSEDT. A vendor event differs from the optional VSI attached to any event. ETDF payload formatting is reserved for TCG definition.
- TCG
- Trusted Computing Group, to which Base reserves the relevant security-event payload definition.
Sources: Base 2.4 §5.2.13.1.14.2.16; 5.2.13.1.14.2.17; 5.2.13.1.14.2.18
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.16; 5.2.13.1.14.2.17; 5.2.13.1.14.2.18, printed pages 267-270, PDF pages 293-296
A forward route through the specification
R-1Frame the problem using the overview and examples, then follow PDF viewer page numbers forward. Finish the Base section and switch to NVM once. The Chinese tutorial explains necessary references without repeated page detours.
| Page order | Start heading | Focus and stop heading |
|---|---|---|
| R1 · Base PDF 270–272 | 5.2.13.1.14 | Start at the section heading, after the preceding table tail. Explain retention/limits and the four ACT operations. Stop before Figure233. |
| R2 · Base PDF 273–277 | Figure233 | Walk from the log header to the event header, then ECRH and the type table. Use the scoped fields taught here. Stop before 5.2.13.1.14.2.1. |
| R3 · Base PDF 278–284 | 5.2.13.1.14.2.1 | Cover SMART, firmware, time, reset and hardware; state what each establishes before reading its payload. Stop before 5.2.13.1.14.2.6. |
| R4 · Base PDF 284–290 | 5.2.13.1.14.2.6 | Cover Namespace, Format, Sanitize, Set Feature and Telemetry. Introduce FLBAS/DPS here and complete their decoding in the final NVM stop. Stop before 5.2.13.1.14.2.13. |
| R5 · Base PDF 291–296 | 5.2.13.1.14.2.13 | Finish thermal, verification, personality, entity mappings and vendor descriptors. Stop after the TCG paragraph, before the next log section. Stop before 5.2.13.1.15. |
| R6 · NVM PDF 76–77 | 4.1.4.4 | Switch documents once. Read the Persistent Event Log heading and Figure112 to finish FLBAS/DPS origins for Create, single Delete and Delete All. Stop before 4.1.4.5. |
- ECRH
- Establish Context and Read Header, the capability for ACT3 and GNUM.
Check your understanding
1. After successful ACT3 returns RCE=0, is ACT1 still needed?
12.01.No. RCE=0 describes absence before processing; ACT3 has established the context and returned the header. Continue with ACT0. ACT1 would now fail because a context exists.
Sources
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, printed pages 245-246,251, PDF pages 271-272,277
2. With EHL21, VSIL4 and EL20, is the record 44 or 48 bytes?
12.02.44. EHL+3 is the 24-byte header; EL20 already includes four VSI bytes, leaving sixteen ED bytes. 48 double-counts VSI and misses the next record’s start.
Sources
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, printed pages 247-251, PDF pages 273-277
3. Does a PEL telemetry header naming nine data blocks include those blocks?
12.03.No. ET0C copies only the first512 header bytes, preserving historical boundaries, reason and generation. It neither contains the full data nor guarantees the same capture remains available.
Sources
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.1; 5.2.13.1.14.2.12; 5.2.13.1.14.2.13, printed pages 252,264-266, PDF pages 278,290-292
4. Does event byte32=12h imply an 18-byte LBA?
12.04.No. Valid FLBAS12h selects format index2 and extended metadata, not size18. First exclude Delete All, where the field is reserved; actual sizes come from the selected format definition.
Sources
Source: NVME-NVM-CS-1.3, Rev. 1.3, §4.1.4.4, printed pages 76-77, PDF pages 76-77
Source: NVME-NVM-CS-1.3, Rev. 1.3, §4.1.5.1; 4.1.6, printed pages 85-87,112-113, PDF pages 85-87,112-113
5. Does SPROG=FFFFh in a sanitize-completion event prove successful sanitization?
12.05.No. Read SOS: for example, 3 means failure. FFFFh also appears outside processing and during Media Verification; it is not a standalone success percentage.
Sources
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.9; 5.2.13.1.14.2.10; 5.2.13.1.14.2.14, printed pages 261-262,266, PDF pages 287-288,292
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.38, printed pages 314-316, PDF pages 340-342
6. Does absence of a feature event prove the host never changed that setting?
12.06.No. Check the feature’s logging policy and support first: it may be prohibited, optional or discouraged. Then consider eviction, frequency suppression and whether the current context predates the change.
Sources
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.11, printed pages 262-264, PDF pages 288-290
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, printed pages 244-245, PDF pages 270-271
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, printed pages 245-246,251, PDF pages 271-272,277
Comments