NVMe scenarios and source figures: lookup routes, field reasoning, worked answers and precise specification locations.
read more
NVMe Figures and Scenarios 07 · Maintenance and Management
NVM Express Base 2.4NVM Command Set 1.3NVMe over PCIe Transport 1.4
LOOKUP · FIELD INTERPRETATION · SOURCE LOCATIONS
NVMe Figures and Scenarios 07 · Maintenance and Management
Separate the requested action, command completion and background result. Firmware commitment, namespace creation and acceptance of a Sanitize command each require different follow-up observations.
Follow a worked scenario through the specification
The returned data below are hypothetical. Start with the need and assumptions, follow the reading route to the relevant fields, then work through the interpretation. Explanations are visible; detailed sources can be expanded.
EXERCISE 03Does firmware stored in slot two mean it is running?
An updater sees a new version string in slot two and marks activation complete. Reinterpret current and next-active fields.
Hypothetical observations and assumptions
- Firmware Slot Information: CAFS=1, NAFS=2; FRS1="A100", FRS2="B200".
- Identify Controller.FR="A100"; FRMW.FAWR=0; no later reset capable of activation is recorded.
Which figures connect this scenario?
This is a specification reading route. The scenario separately explains action order and wait conditions.
- Read the running revision and activation capability
Identify Controller FR reports the running revision; FRMW supplies slot and activation capabilities.
Base 2.4 · Figure 338 - Read current and next-active slots
Read CAFS and NAFS from Firmware Slot Information AFI and compare the slot revision strings.
Base 2.4 · Figure 215 - Connect the Commit action and completion conditions
Use the Firmware Commit action and completion rules to determine when activation occurs, then reread the revision afterward.
Base 2.4 · Figure 187
Follow the field interpretation
Lookup sequence: Identify CNS=01h FR/FRMW → LID=03h AFI and slot revisions → Firmware Commit action/status and reset trace.
Step 1CAFS=1 and FR=A100 support that slot one’s revision is still running. FRS2=B200 identifies a revision in slot two, not that it is currently executing.
Step 2NAFS=2 identifies the slot scheduled for the next Controller Level Reset capable of activation. FAWR=0 means no reset-free activation support; an unspecified reset is not enough to establish activation.
Step 3After the applicable activation step, reread FR and CAFS and compare against the intended revision. This exercise identifies evidence of pending activation without performing a reset or download.
Detailed source locations
- Base 2.4 · §5.2.13.1.4 · Figure 215 · Firmware Slot Information Log Page · Printed pages 226 · PDF 252
- Base 2.4 · §5.2.9 · Figure 187 · Firmware Commit – Command Dword 10 · Printed pages 203 · PDF 229
- Base 2.4 · §5.2.14.2.1 · Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent · Printed pages 340–341, 354 · PDF 366–367, 380
- Base 2.4 · §5.2.9 · Printed pages 202–205 · PDF 228–231
Continue with the other scenarios
EXERCISE 01Can a single namespace support Overwrite Sanitize?
The requirement is to sanitize only NSID=7 using Sanitize Namespace with Overwrite. Is Identify OWS=1 sufficient?
- NSID
- Namespace Identifier
Hypothetical observations and assumptions
- Base Revision 2.4; SANICAP.OWS=1 and CES=1; assume Commands Supported and Effects also reports Sanitize Namespace support.
- The requested target is one namespace; expanding sanitization to the entire NVM subsystem is not permitted.
Follow the field interpretation
Lookup sequence: First check operations defined by Base §5.2.27 → Identify CNS=01h SANICAP → command support in Commands Supported and Effects → target namespace state.
Step 1This revision defines only Crypto Erase as a starting operation for Sanitize Namespace. In Figure 454, SANACT=011b—the value used for Overwrite in the other command—is reserved. The requested combination is therefore not provided by this standard command.
Step 2SANICAP.OWS=1 reports Overwrite sanitize support; it does not add a legal action to Sanitize Namespace. Distinguish command and target scope before interpreting the capability.
Step 3Report that single-namespace Overwrite Sanitize is not defined by this revision, then resolve whether an alternative such as namespace Crypto Erase satisfies the requirement. Do not silently substitute subsystem Overwrite or claim ordinary Writes provide Sanitize guarantees.
Detailed source locations
- Base 2.4 · §5.2.27 · Printed pages 452–453 · PDF 478–479
- Base 2.4 · §5.2.27 · Figure 454 · Sanitize Namespace – Command Dword 10 · Printed pages 453 · PDF 479
- Base 2.4 · §5.2.14.2.1 · Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent · Printed pages 361–362 · PDF 387–388
- Base 2.4 · §5.2.26 · Figure 451 · Sanitize – Command Dword 10 · Printed pages 450–451 · PDF 476–477
- Base 2.4 · §5.2.13.1.6 · Figure 217 · Commands Supported and Effects Data Structure · Printed pages 228–229 · PDF 254–255
EXERCISE 02Does one sanitized namespace establish subsystem-wide sanitization?
A validator uses NSID=7’s success to claim subsystem sanitization and capacity for four additional concurrent operations. Which claims exceed the evidence?
- NSID
- Namespace Identifier
Hypothetical observations and assumptions
- LID=81h, NSID=7: STNSID=7, SOS=1, MNSOIP=FFFFFFFFh.
- A separate subsystem-target query (NSID=0) reports MNSOIP=4; other ongoing namespace sanitizations have not been inventoried.
Follow the field interpretation
Lookup sequence: Get Log Page LID=81h, distinguishing subsystem targets NSID=0/FFFFFFFFh from allocated-NSID namespace targets.
Step 1STNSID=7 confirms the namespace target. SOS=1 reports successful sanitization for that target with its state machine in Idle; it says nothing equivalent about other namespaces.
Step 2For a namespace target, MNSOIP is required to be FFFFFFFFh; it does not permit billions of concurrent operations. The subsystem value four limits total concurrent operations, not four remaining slots.
Step 3Remaining capacity requires complete, time-consistent information about ongoing operations and concurrent management changes. Even an available slot and accepted command still require target-specific final-result verification.
Detailed source locations
- Base 2.4 · §5.2.13.1.38 · Figure 312 · Sanitize Status Log Page · Printed pages 314–319 · PDF 340–345
- Base 2.4 · §5.2.27 · Printed pages 452–453 · PDF 478–479
EXERCISE 04Does a Format NSID always confine its effects to one namespace?
A request intends secure erase only for NSID=7. Review checks the command NSID and accepts it. Which scope evidence is missing?
Hypothetical observations and assumptions
- OACS.FNVMS=1; FNA.FNS=0, SENS=1, FNVMBS=0.
- Proposed Format NVM: NSID=7, SES=1; other format fields are valid. The command is not executed in this exercise.
Follow the field interpretation
Lookup sequence: Identify CNS=01h OACS/FNA → Format NVM NSID, SES and format parameters.
Step 1FNS sets the formatting scope; SENS sets the secure-erase scope. FNS=0 does not cancel SENS=1; the requested secure erase affects all namespaces in the subsystem.
Step 2The combination fails the requirement to erase only namespace seven. An explicit command NSID must still be interpreted with controller attributes; it does not by itself bound every effect.
Step 3FNVMBS also uses an easily misread direction: one means FFFFFFFFh broadcast is unsupported. Establish scope before deciding whether an operation meets the requirement.
Detailed source locations
- Base 2.4 · §5.2.14.2.1 · Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent · Printed pages 353, 373 · PDF 379, 399
- Base 2.4 · §5.2.11 · Figure 195 · Format NVM – Command Dword 10 · Printed pages 208–209 · PDF 234–235
- NVM Command Set 1.3 · §4.1.1 · Figure 91 · Format NVM – Command Dword 10 – NVM Command Set Specific Fields · Printed pages 63 · PDF 63
EXERCISE 05Does an unsaveable protection feature clear on reset?
A tool sees SVBL=0 for FID=84h and claims a reset clears all namespace write protection. Compare two namespaces.
Hypothetical observations and assumptions
- Get Features FID=84h, SEL=0: NSID=2 has WPS=2; NSID=9 has WPS=3.
- These states are supported; the planned action is only a Controller Level Reset, without a power cycle.
Follow the field interpretation
Lookup sequence: Identify CNS=01h NWPC → Get Features FID=84h, SEL=0 for each current WPS → apply §8.1.18 state-persistence rules.
Step 1WPS=2 is Write Protect Until Power Cycle and persists across Controller Level Reset without power cycling. The stated reset does not unprotect NSID=2; an actual power cycle is the defined release condition.
Step 2WPS=3 is Permanent Write Protect; a power cycle is not its release mechanism. Supported protection states, permission to enter them and current state are separate questions.
Step 3SVBL=0 describes whether the feature accepts a save request, not state persistence. Retain NWPC, relevant WPC permissions and WPS rather than deriving recovery behavior from one saveability bit.
Detailed source locations
- Base 2.4 · §5.2.30.1.38 · Figure 541 · Write Protection – Command Dword 11 · Printed pages 512 · PDF 538
- Base 2.4 · §5.2.12 · Figure 201 · Completion Queue Entry Dword 0 when Select is set to 11b · Printed pages 212 · PDF 238
- Base 2.4 · §5.2.14.2.1 · Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent · Printed pages 375 · PDF 401
- Base 2.4 · §8.1.18 · Printed pages 664–666 · PDF 690–692
EXERCISE 06Does zero mean the same for Boot and namespace protection?
A shared decoder displays every protection state zero as unprotected. Which interpretation fails for this command and response?
Hypothetical observations and assumptions
- A prior Set Features FID=85h used BP0WPS=0 and BP1WPS=0 and succeeded.
- Current Get Features FID=85h, SEL=0 reports BP0WPS=2 and BP1WPS=4.
Follow the field interpretation
Lookup sequence: Distinguish Namespace Write Protection FID=84h from Boot Partition Write Protection FID=85h, then distinguish Set requests from Get responses.
Step 1For FID=85h, Set value zero requests no change for that partition, not unlocking. A successful all-zero request may leave both unchanged and is not evidence of protection removal.
Step 2Current BP0WPS=2 means partition zero is Write Locked; BP1WPS=4 means partition one’s protection is controlled by RPMB. Four is a reportable state, not a general Set request value.
Step 3Get does not return zero as either partition’s state, so a decoder needs at least FID and direction. Shared multi-domain partitions have additional specific restrictions; the namespace WPS table cannot stand in for them.
Detailed source locations
- Base 2.4 · §5.2.30.1.39 · Figure 542 · Boot Partition Write Protection Config - Command Dword 11 · Printed pages 513–514 · PDF 539–540
- Base 2.4 · §5.2.30.1.38 · Figure 541 · Write Protection – Command Dword 11 · Printed pages 512 · PDF 538
01Firmware Commit – Command Dword 10
Base 2.4 · Figure 187 · Firmware Commit – Command Dword 10
§5.2.9 · Printed pages 203 · PDF 229
01.1 · UseIf a download did not change the running revision, inspect Commit Action to distinguish placement, activation after reset and immediate activation. Download and commit are separate steps.
01.2 · Fields and relationshipsFS bits 2:0 selects a slot, with zero letting the controller choose. CA bits 5:3 values 0/1/2/3 mean place without activation, place and activate at next Controller Level Reset, activate an existing slot at that reset, or activate immediately. CA=6/7 concern Boot Partitions with BPID bit 31.
01.3 · Interpretation and exampleAfter successful CA=1, the running firmware may still be old. Compare current and next-active slots and check whether completion specifies a particular reset requirement.
Back to this volume’s figure index02Firmware Image Download – Command Dword 10
Base 2.4 · Figure 191 · Firmware Image Download – Command Dword 10
§5.2.10 · Printed pages 205 · PDF 231
02.1 · UseDecode each firmware-download chunk length here. The whole-image size is not automatically the size of every command.
02.2 · Fields and relationshipsCDW10.NUMD bits 31:0 encodes Dword count minus one, giving 4×(NUMD+1) bytes. Combine it with CDW11.Offset and Identify.FWUG for chunk placement and granularity.
02.3 · Interpretation and exampleA4096-byte chunk uses NUMD=1023, not 4096. Record length and image offset separately; correct length alone does not satisfy offset or FWUG requirements.
Back to this volume’s figure index03Firmware Slot Information Log Page
Base 2.4 · Figure 215 · Firmware Slot Information Log Page
§5.2.13.1.4 · Printed pages 226 · PDF 252
03.1 · UseUse this log to distinguish stored and running firmware. A revision string in a slot does not make it active.
03.2 · Fields and relationshipsIn AFI byte 0, CAFS bits 2:0 is the active slot and NAFS bits 6:4 the slot for the next reset able to activate it; NAFS=0 means unspecified. FRS1–7 are eight-byte revisions starting at byte 8.
03.3 · Interpretation and exampleCAFS=1/NAFS=2 with a new slot 2 revision means firmware was loaded from slot 1 while slot 2 awaits activation. A zero FRS can mean unsupported slot or no valid revision; it does not distinguish them.
Back to this volume’s figure index04Device Self-test – Command Dword 10
Base 2.4 · Figure 177 · Device Self-test – Command Dword 10
§5.2.6 · Printed pages 199 · PDF 225
04.1 · UseSTC chooses the requested self-test action. Command completion differs from completion of the background test; inspect the log for its outcome.
04.2 · Fields and relationshipsCDW10.STC bits 3:0 values 1/2/3 start short, extended or Host-Initiated Refresh operations; Eh is vendor-specific and Fh aborts. NSID and capabilities separately determine target and applicability.
04.3 · Interpretation and exampleAfter a successful STC=2 submission, an extended test may still be in progress in the log. Admin CQE success is not proof that the test passed.
- CQE
- Completion Queue Entry
05Device Self-test Log Page
Base 2.4 · Figure 218 · Device Self-test Log Page
§5.2.13.1.7 · Printed pages 230 · PDF 256
05.1 · UseThis layout separates the current operation from historical outcomes. The first two bytes describe progress; the result list describes success or failure.
05.2 · Fields and relationshipsCDSTO byte 0 low 4 bits identifies the current operation; CDSTC byte 1 low 7 bits gives completion percentage. Ignore progress when DSTOS=0. Twenty 28-byte results begin at byte 4, newest completed or aborted operation first.
05.3 · Interpretation and exampleIf byte 1 still contains 25 but DSTOS is zero, do not report a test stuck at 25%. Read the newest result for completion, command abort, reset abort or another cause.
Back to this volume’s figure index06Self-test Result Data Structure
Base 2.4 · Figure 219 · Self-test Result Data Structure
§5.2.13.1.7 · Printed pages 231–232 · PDF 257–258
06.1 · UseInterpret an individual test result here, distinguishing detected failures from aborted operations. Diagnostic fields are not universally valid.
06.2 · Fields and relationshipsDSTS byte 0 high 4 bits gives test type and low 4 result; SEGN byte 1 is valid for a specific result. VDINFO byte 2 independently validates NSID, FLBA, SCT and SC. POH bytes 11:4 timestamps completion/abort in power-on hours; NSID bytes 15:12 and FLBA bytes 23:16 identify the failing target.
- SCT
- Status Code Type
06.3 · Interpretation and exampleIf FVLD is zero, all-zero FLBA bytes do not establish failure at LBA 0. DSTR=2 means a Controller Level Reset aborted the test, not a detected media failure.
- LBA
- Logical Block Address
07Namespace Attachment – Command Dword 10
Base 2.4 · Figure 443 · Namespace Attachment – Command Dword 10
§5.2.24 · Printed pages 445 · PDF 471
07.1 · UseWhen a namespace exists but is inaccessible through one controller, inspect attachment and the controller list. Creating storage and making it accessible through a controller are different operations.
07.2 · Fields and relationshipsCDW10.SEL bits 3:0 values 0/1 mean Attach/Detach; other values are reserved. NSID chooses the namespace and a buffer lists target controllers. These SEL meanings differ from Namespace Management.
07.3 · Interpretation and exampleDetach is not Delete: it removes an association. On list-processing failure, Error Information can locate the first failed entry by byte offset; do not assume later controllers were processed.
Back to this volume’s figure index08Namespace Management – Command Dword 10
Base 2.4 · Figure 446 · Namespace Management – Command Dword 10
§5.2.25 · Printed pages 446–447 · PDF 472–473
08.1 · UseThis selector distinguishes namespace-management actions that share one opcode. Opcode alone cannot tell Create from Delete.
08.2 · Fields and relationshipsCDW10.SEL bits 3:0 values 0/1/2 select Create, Delete or Restore Default Namespace Configuration. Other bits are reserved. Buffer and NSID interpretation depends on the action; Create also uses CSI to select its format.
- CSI
- Command Set Identifier
08.3 · Interpretation and exampleA successfully returned new NSID establishes creation, not attachment to the desired controller. Restore means the default namespace configuration, not restoration of an arbitrary backup snapshot.
Back to this volume’s figure index09Namespace Management – Host Specified Fields
NVM Command Set 1.3 · Figure 134 · Namespace Management – Host Specified Fields
§4.1.6 · Printed pages 112–113 · PDF 112–113
09.1 · UseThis table lists host-specified positions for NVM namespace creation. It reuses only part of Identify, so a complete Identify response is not an unmodified Create payload.
09.2 · Fields and relationshipsNSZE occupies bytes 7:0, NCAP bytes 15:8, FLBAS byte 26, DPS byte 29 and NMIC byte 30, followed by group identifiers. LBSTM occupies bytes 391:384. FDP uses NPHNDLS bytes 393:392 and the Placement Handle list from 512; reserved areas follow the Create definition.
- FDP
- Flexible Data Placement
09.3 · Interpretation and exampleWith FDP supported and enabled, the list maps placement handles to RUHs. Otherwise those bytes cannot establish a valid mapping. NSZE/NCAP still count blocks of the chosen format, not bytes.
- FDP
- Flexible Data Placement
10Format NVM – Command Dword 10
Base 2.4 · Figure 195 · Format NVM – Command Dword 10
§5.2.11 · Printed pages 208–209 · PDF 234–235
10.1 · UseDecode the selected format and erase request here. Base supplies the common envelope; NVM defines PI and metadata semantics.
- PI
- Protection Information
10.2 · Fields and relationshipsLBAFL bits 3:0 with LBAFU bits 13:12 forms the format index, with LBAFU subject to LBAFEE. SES bits 11:9 values 0/1/2 request no secure erase, User Data Erase or Cryptographic Erase. PIL bit 8, PI bits 7:5 and MSET bit 4 are command-set-specific.
- PI
- Protection Information
10.3 · Interpretation and exampleA format index selects a list entry, not a byte size. SES=1 does not guarantee zero-filled data; a validator that accepts only zeros can reject permitted post-erase contents.
Back to this volume’s figure index11Format NVM – Command Dword 10 – NVM Command Set Specific Fields
NVM Command Set 1.3 · Figure 91 · Format NVM – Command Dword 10 – NVM Command Set Specific Fields
§4.1.1 · Printed pages 63 · PDF 63
11.1 · UseThis table fills the three NVM-specific fields left by Base Format. PI type and Guard width are different selections; Type 3 does not mean 64-bit Guard.
11.2 · Fields and relationshipsMSET bit 4 chooses extended LBA or separate metadata. PI bits 7:5 disables protection at 0 or selects Types 1/2/3. PIL bit 8 chooses PI position; NVM Command Set 1.0 and later requires PIL=0, placing PI at the metadata tail.
- LBA
- Logical Block Address
11.3 · Interpretation and exampleMSET=1/PI=1 selects extended LBA with Type 1 protection. Obtain metadata size and Guard format from the selected LBAF/ELBAF instead of inferring them from these two controls.
Back to this volume’s figure index12Sanitize – Command Dword 10
Base 2.4 · Figure 451 · Sanitize – Command Dword 10
§5.2.26 · Printed pages 450–451 · PDF 476–477
12.1 · UseDecode subsystem-wide sanitize action, overwrite passes and subsequent-state options here. Acceptance of the command and completion of sanitization require separate observations.
12.2 · Fields and relationshipsSANACT bits 2:0 selects 1 exit failure, 2 Block Erase, 3 Overwrite, 4 Crypto Erase or 5 exit Media Verification. AUSE bit 3 selects completion mode. OWPASS bits 7:4/OIPBP bit 8 apply to overwrite; NDAS bit 9, EMVS bit 10 and PREQ bit 11 control deallocation, verification and purge requests.
12.3 · Interpretation and exampleFor overwrite, OWPASS=0 means 16 passes, not none. After acceptance, inspect LID=81h and SOS; Admin CQE success or a single SPROG value does not prove successful sanitization.
- CQE
- Completion Queue Entry
13Sanitize Namespace – Command Dword 10
Base 2.4 · Figure 454 · Sanitize Namespace – Command Dword 10
§5.2.27 · Printed pages 453 · PDF 479
13.1 · UseNamespace Sanitize has its own CDW10 layout. Do not copy every control bit from subsystem Sanitize.
13.2 · Fields and relationshipsValid controls include SANACT bits 2:0, AUSE bit 3, PREQ bit 4 and EMVS bit 10. Crypto Erase 4 starts an operation; Block Erase and Overwrite encodings are reserved here. Bits 9:5 and 31:11 are reserved.
13.3 · Interpretation and exampleCDW10=0000041Ch contains SANACT=4, AUSE=1, PREQ=1 and EMVS=1. Placing PREQ at the subsystem command’s bit 11 instead writes a reserved bit, not a purge request.
Back to this volume’s figure index14Sanitize Status Log Page
Base 2.4 · Figure 312 · Sanitize Status Log Page
§5.2.13.1.38 · Printed pages 314–319 · PDF 340–345
14.1 · UseThis log reports progress, the latest outcome and current sanitize state. Determine whether the queried target is a subsystem or namespace before decoding scope-dependent fields.
14.2 · Fields and relationshipsSPROG bytes 1:0 is a progress fraction; SOS distinguishes never run, success, processing and failure. SCDW10 records starting parameters. Estimated-time fields have individual zero/FFFFFFFFh meanings. SSI supplements state/failure details alongside erased-state and STNSID information.
14.3 · Interpretation and exampleSPROGFFFFh alone is not success: SOS=3 still means failure. Decode SCDW10 using Figure 451 or 454 according to target, especially the different PREQ position.
Back to this volume’s figure index15Write Protection – Command Dword 11
Base 2.4 · Figure 541 · Write Protection – Command Dword 11
§5.2.30.1.38 · Printed pages 512 · PDF 538
15.1 · UseWhen writes are rejected, inspect namespace WPS to distinguish reversible, power-cycle-bound and permanent protection. Boot Partition protection uses different encodings.
15.2 · Fields and relationshipsCDW11.WPS bits 2:0 values 0/1/2/3 mean unprotected, protected, until-power-cycle and permanent. NWPC and Write Protection Control separately govern capability and entry permission; WPS describes requested/reported state.
15.3 · Interpretation and exampleOnce WPS=2 or 3 is entered, requesting 0 through Set Features returns Feature Not Changeable. SEL=3.CHANG=1 does not make a permanent current state reversible.
Back to this volume’s figure index16Boot Partition Write Protection Config - Command Dword 11
Base 2.4 · Figure 542 · Boot Partition Write Protection Config - Command Dword 11
§5.2.30.1.39 · Printed pages 513–514 · PDF 539–540
16.1 · UseCheck each Boot Partition’s protection when updates are blocked. Zero does not mean unprotected as it does for namespace WPS.
16.2 · Fields and relationshipsBP0WPS bits 2:0 and BP1WPS bits 5:3 encode 0 no requested change (Set only), 1 unlocked, 2 locked and 3 locked until power cycle. Value 4 reports RPMB-controlled protection and is reserved for Set. Both default to locked.
16.3 · Interpretation and exampleTo unlock partition 0 while leaving partition 1 unchanged, use 1 and 0, producing CDW11=1. Clearing both fields does not unlock both partitions. If CTRATT.MDS=1 and multiple controllers share the Boot Partition, requesting state 3 (locked until power cycle) fails with Feature Not Changeable.
Back to this volume’s figure index
Comments