NVMe Base 2.4: Sanitize: targets, methods, and completion
00.01.Sanitize handles data sanitization. Establish the target, method, current controller state, and evidence of completion. Acceptance of the initiating command and completion of sanitization must be checked separately.
- controller
- Controller, the entity that implements the NVMe interface, fetches commands, and reports completions.
The main ideas
Establish the sanitization target
01-01Identify the data classes and scope before checking supported sanitization capabilities.
Choose a method and parameters
02-01Compare block erase, overwrite, and crypto erase, then select parameters that apply to the chosen method.
Separate acceptance, progress, and completion
03-01Successful command completion does not prove sanitization is finished. Use the status log to follow progress and outcome.
Interpret reads after sanitization
04-01Media verification and ordinary reads serve different purposes. Interpret returned data using the NVM Command Set rules.
- NVM
- Non-Volatile Memory, memory that retains data without power.
Connecting the main ideas
00.02.Select the target and supported method, then encode method-specific parameters. Read status to distinguish progress, success, and failure. Media verification has separate access rules; post-sanitize data interpretation follows the NVM Command Set.
01 Define the sanitization target first
01.01.Sanitize scope is not simply everything on a disk. Classify the target, data provenance, and whether it can contain user data; this also establishes its relationship with Boot and diagnostics.
01.02.Subsystem and namespace sanitize cover different data. Sanitizing every namespace individually is not equivalent to subsystem sanitize and does not thereby set subsystem GDE to one. Neither affects Boot Partitions or RPMB; logs/features containing user data may need modification.
- namespace
- Namespace, a formatted quantity of non-volatile memory accessed by a host through a controller.
Sources: Base 2.4 §8.1.27
Source: NVME-BASE-2.4, Rev. 2.4, §8.1.27, printed pages 711-712, PDF pages 737-738
| Target or method | Included or excluded data | Scope of the resulting conclusion |
|---|---|---|
| Boot/RPMB | Unaffected by sanitize | Managed by their own mechanisms |
| Logs/features | Modify user data when necessary | Namespace media alone is insufficient |
| All namespace sanitizes | Complete work on each target | Does not thereby establish subsystem GDE |
| Crypto Erase | Changes keys and handles unencrypted data | Old key copies matter too |
02 Combining command parameters with capabilities
02.01.Separate advertised capabilities, command requests, and Feature policy. Command acceptance, operation success, and satisfaction of no-deallocate are three outcomes requiring different evidence.
02.02.CDW10 contains SANACT[2:0], AUSE[3], OWPASS[7:4], OIPBP[8], NDAS[9], EMVS[10], and PREQ[11]; CDW11 contains OVRPAT. SANACT 001b selects Exit Failure Mode, 010b Block Erase, 011b Overwrite, 100b Crypto Erase, and 101b Exit Media Verification; other values are reserved.
- SANACT
- Sanitize Action; selects the method, Exit Failure Mode, or Exit Media Verification.
- AUSE
- Allow Unrestricted Sanitize Exit; selects whether failure can be exited without a successful retry.
- EMVS
- Enter Media Verification State; requests verification after successful processing, subject to method and capability restrictions.
- NDAS
- No-Deallocate After Sanitize; a command request interpreted with SANICAP.NDI and NODRM.
- PREQ
- Purge Request; interpreted with SPRRS for purge request/reporting; its bit position differs between the Sanitize commands.
- CDW
- CDW (Command Dword): a 32-bit command field. In CDW10, 10 is the field index, not a byte offset.
Sources: Base 2.4 §5.2.26
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.26, printed pages 448-451, PDF pages 474-477
| Command and capability combination | Controller handling | Reason for acceptance or rejection |
|---|---|---|
| NDAS=1, NDI=0 | Successful sanitize must not deallocate | Other validity conditions still apply |
| NDAS=1, NDI=1, NODRM=0 | Command rejected | Invalid Field in Command |
| NDAS=1, NDI=1, NODRM=1 | Processing permitted | Success can report SOS=100b |
| EMVS=1 | Subsystem requires VERS=1 | Block/Crypto + NDAS=0 |
- NODRM
- No-Deallocate Response Mode; FID 17h bit zero selects error or warning for inhibited NDAS.
- NDI
- No-Deallocate Inhibited; advertises whether the controller inhibits NDAS.
- SOS
- Sanitize Operation Status; SSTAT bits 2:0, interpreted separately from the current SANS state.
03 Background sanitize state and progress
03.01.Start with the seven states in Figure 772 and attach transition conditions from Figures 773–779. Status describes results, state describes the current position, and events report transitions.
03.02.Sanitize runs in the background. Starting an operation updates LID 81h before completing its initiating command; the host uses the status log and events for subsequent progress. An active operation cannot be aborted and continues across reset/power cycle, although specified resets may cancel verification.
- Host
- The system running the operating system and issuing NVMe commands.
- LID
- Log Page Identifier: selects the type of log page to read.
Sources: Base 2.4 §5.2.26.1; 8.1.27.1
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.26.1; 8.1.27.1, printed pages 451,712-713, PDF pages 477,738-739
| Operation phase | Allowed subsequent action | Progress and history reporting |
|---|---|---|
| Restricted Failure | Retry in restricted mode | Exit Failure Mode cannot escape it |
| Unrestricted Failure | Retry or Exit Failure Mode | Idle does not rewrite failure history |
| Media Verification | Processing succeeded | The operation is still Sanitizing |
| Post-Verification Deallocation | SPROG starts again at zero | Failure records FAILS=6h |
- SPROG
- Sanitize Progress; raw/65536, indicating progress only for the currently measured phase.
04 Restrictions and verification reads
04.01.Evaluate the command allowlist and the NVM Read exception separately. Determine target/state, then PI checking and allocation; ordinary-read behavior cannot be applied unchanged to verification.
- PI
- Protection Information: Guard and tag fields used to check data and its associated information.
04.02.During subsystem sanitize, Figure 144 identifies allowed Admin commands and log pages; Boot Partition is listed but Telemetry 07h/08h is not. Disallowed operations are restricted with Sanitize In Progress. Namespace sanitize instead uses Figures 145/146 and the target NSID. NVM Reads in Media Verification have a specific exception.
- Admin
- Administrative, the control path used to create, configure, query, or manage controllers and queues.
- NSID
- Namespace Identifier, a controller-visible numeric handle for a namespace; the identifier is not the namespace object itself.
Sources: Base 2.4 §8.1.27.5; 5.1.1-5.1.2
Source: NVME-BASE-2.4, Rev. 2.4, §8.1.27.5; 5.1.1-5.1.2, printed pages 178-181,730-732, PDF pages 204-207,756-758
| Verification-read condition | Returned content or status | What the result establishes |
|---|---|---|
| PI checking requested | Invalid Field in Command | Not permitted for verification reads |
| Allocated media readable | Return media data | Integrity errors can be ignored when readable |
| Allocated media unreadable | Unrecovered Read Error | Do not invent data |
| Deallocated LBA | Use deallocated/unwritten rules | Not evidence of the old media pattern |
Where to continue in the specification
05.01.Use the flow above to frame the problem, then open the corresponding sections for fields and full conditions. The Chinese tutorial also explains every in-scope figure with its takeaway, example, and details.
| Concept to explain | Specification sections |
|---|---|
| Define the sanitization target first | Base 2.4 §8.1.27 · Base 2.4 §8.1.27.2-8.1.27.3 · NVM 1.3 §5.12 |
| Combining command parameters with capabilities | Base 2.4 §5.2.26 · Base 2.4 §8.1.27.1; 5.2.27 · Base 2.4 §5.2.30.1.16; 8.1.27.2-8.1.27.3 · Base 2.4 §5.2.26; 8.1.27.1 · Base 2.4 §5.2.26; 8.1.27.3 |
| Background sanitize state and progress | Base 2.4 §5.2.26.1; 8.1.27.1 · Base 2.4 §8.1.27.4 · Base 2.4 §8.1.27.4.6-8.1.27.4.7 · Base 2.4 §5.2.13.1.38 · Base 2.4 §5.2.13.1.38; 8.1.27.3 · Base 2.4 §8.1.27.1; 8.1.27.4 |
| Restrictions and verification reads | Base 2.4 §8.1.27.5; 5.1.1-5.1.2 · Base 2.4 §8.1.27.5 · NVM 1.3 §4.1.7; 5.12 · NVM 1.3 §5.12 · NVM 1.3 §5.12.1 |
Check your understanding
1. Does Successful Completion of the Sanitize command mean sanitization has finished?
06.01.It indicates success of the initiating command; the background operation may still be running. Use the corresponding Sanitize Status to determine the operation state. SPROG and time estimates describe progress and do not replace the final status.
Sources
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.26.1; 8.1.27.1, printed pages 451,712-713, PDF pages 477,738-739
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.38, printed pages 313-319, PDF pages 339-345
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.38; 8.1.27.3, printed pages 314-319,718, PDF pages 340-345,744
2. Why is an all-zero readback not a universal success criterion for sanitization?
06.02.Methods have different read-value rules, and deallocation selects another set of rules. Block Erase, Crypto Erase, and Overwrite do not share one expected pattern; Media Verification also has its own read semantics. Establish the operation state before interpreting data by method and block state.
Sources
Source: NVME-BASE-2.4, Rev. 2.4, §8.1.27.2-8.1.27.3, printed pages 714-717, PDF pages 740-743
Source: NVME-NVM-CS-1.3, Rev. 1.3, §5.12, printed pages 174, PDF pages 174
Source: NVME-NVM-CS-1.3, Rev. 1.3, §5.12.1, printed pages 174-175, PDF pages 174-175


Comments