NVMe · Q1–328

NVM Express Base 2.4NVM Command Set 1.3NVMe over PCIe Transport 1.4

Q118–Q135

Format and sanitize

Format changes namespace format; sanitize removes data. Compare scope, completion and reset behavior across the operation lifecycle.

Each question is followed by its explanation. Start with the volume overview, then follow the field interpretations, comparisons or processes. Essential conditions and the normal path are visible from the start. All numerical examples are hypothetical. Status is written SCT/SC; h indicates hexadecimal.

SCT: Status Code Type

Three distinct operation paths

Subsystem overwrite support does not enable namespace overwrite.

Operation	Main selectors	Completion evidence
Format NVM	Format, metadata, PI and SES	Format CQE and resulting format
Subsystem sanitize	Action and options	Initiation CQE followed by status
Namespace sanitize	NSID and crypto erase	Target namespace status

PI: Protection Information
CQE: Completion Queue Entry
NSID: Namespace Identifier

Worked interpretation: OWS1 advertises subsystem overwrite. Base 2.4 namespace sanitize permits crypto erase, not copied SANACT3 overwrite.

Sources: Base 2.4 §5.1.1, 5.2.11 · NVM Command Set 1.3 §4.1.2 · Base 2.4 §5.2.26–5.2.27 · Base 2.4 §5.2.13.1.38 · Base 2.4 §8.1.27.1–8.1.27.5

Review the terminology when needed

Controller / namespace: A controller receives commands and manages access. A namespace is a logical storage space that commands can address. An NVM subsystem contains controllers and nonvolatile storage resources.
SQ / CQ / SQE / CQE: Submission and Completion Queues carry command entries (SQEs) and completion entries (CQEs). QID identifies a queue, CID distinguishes outstanding commands in one SQ, and NSID identifies a namespace.
Register / Identify / Feature / Log: A register exposes control or state. Identify queries capabilities and attributes; features query or configure operation; log pages report specific state or records. FID, LID, CNS and CSI select features, logs, Identify structures and command sets.
index / offset / zero-based: An index selects an entry, usually starting at 0; an offset measures distance from an origin in specified units. A zero-based count encodes count−1, but not every zero-valued field is a count. A Dword is 4 bytes; a byte is 8 bits.
Scope / reset / retention: Scope names the affected objects; retention means preserving state. Controller Reset (clearing CC.EN) is one form of Controller Level Reset, or CLR. Different CLR triggers can retain different registers.

Questions in this volume

Q118 · How is support for Format, Sanitize and Sanitize Namespace discovered?
Q119 · How do Format, secure erase and the two sanitize targets differ?
Q120 · How are Format data format, metadata, PI and SES selected?
Q121 · How are invalid Format parameters and states reported?
Q122 · Which Admin operations can continue during Format?
Q123 · How is interrupted Format assessed after reset or power loss?
Q124 · Which namespace data must be refreshed after Format?
Q125 · How are Format failures checked using CQE, Error Log and PEL?
Q126 · How does SANICAP advertise sanitize methods?
Q127 · How do NDAS, overwrite pattern, passes and inversion work?
Q128 · How are progress, status, state and erased-data flags interpreted together?
Q129 · Which commands are permitted during subsystem sanitization?
Q130 · Does sanitization continue across reset or power loss?
Q131 · How do success, failure and failure mode differ in the log?
Q132 · What does Exit Failure Mode accomplish?
Q133 · When are sanitize AERs and persistent events generated?
Q134 · How is namespace sanitization targeted and isolated?
Q135 · How are invalid or unsupported namespace sanitize requests handled?

Q118 How is support for Format, Sanitize and Sanitize Namespace discovered?

Task: determine Sanitize Namespace support using queries only. Follow the command opcode into its supported-command entry and support bit.

Follow the explanation

Opcode support, supported action and current permission are distinct; Sanitize support does not enable every erasure method.

1. Select the target and information

Format scope depends on FNA, SES and NSID; subsystem and namespace sanitization use distinct commands and targets.

NSID: Namespace Identifier

Use OACS/FNA for Format and SANICAP CES/BES/OWS for Sanitize. For the Sanitize Namespace command itself, find Admin opcode 8Ch in Figure 28, then decode bit 0 (CSUPP) of its Admin entry in LID 05h using Figure 217. CSUPP declares command support; CES and NVERS separately describe the method and namespace media-verification capability.

LID: Log Page Identifier

Worked lookup: from Sanitize Namespace to CSUPP

All values below are hypothetical. Use one PCIe I/O controller, CC.CSS=000b and UUID Index 0; decode buffers only after successful queries. Figure 28 is the specification’s command catalog, not the device’s measured capability list.

Step and source location	Information to retrieve	What this establishes
1 · Figure 28, printed 46/PDF 72	Sanitize Namespace → Admin opcode 8Ch; O means optional.	Identifies the command and encoding. Optional does not establish this controller’s support.
2 · Identify Controller, Figure 338, printed 355,361–362/PDF 381,387–388	CNS 01h; assume LPA.CSES=1, SANICAP.CES=1 and NVERS=0. CSES is LPA bit 1.	Effects log and Crypto Erase are supported; namespace media verification is not. CES alone does not replace 8Ch support discovery.
3 · Get Log Page, Figures 204–208, printed 213–215/PDF 239–241	Opcode 02h, LID 05h, NSID 0, NUMDL=03FFh, NUMDU=0, LPO=0, OT=0 and RAE=0 retrieve 4096 bytes.	NUMD encodes count−1: (03FFh+1)×4=4096 bytes. This reads a directory without submitting opcode 8Ch.
4 · Figure 216, printed 227/PDF 253	Admin entries begin at byte 0 and occupy 4 bytes each. 8Ch=140, so offset 4×140=560=230h selects bytes 560–563.	This Admin entry does not use the I/O region’s 1024-byte base. For a partial read, subtract that segment’s starting byte offset to find the buffer-relative position.
5 · Figure 217, printed 228–229/PDF 254–255	Hypothetical bytes 03h,00h,01h,00h form little-endian 00010003h; bit 0=1.	CSUPP=1 advertises 8Ch. LBCC=1 and CSE=001b additionally describe possible data change and same-namespace coordination recommendations, not an operation result.
6 · §5.2.27/Figure 454, printed 452–453/PDF 478–479	Namespace initiation uses SANACT100b (Crypto Erase);010b/011b are reserved. Check active NSID, protection and concurrency before execution.	Command support does not establish namespace Overwrite or current eligibility of every target. NVERS=0 also does not provide entry to Media Verification.

CNS: Controller or Namespace Structure, selecting Identify data

A valid entry with CSUPP=0 reports no command support and requires its other fields to be zero. CSES=0 or a failed log query instead leaves this route without valid support evidence; neither is an observed CSUPP=0.

Sources: Base 2.4 §3.1.3.4 (Figure 28 PCIe I/O-controller rows and O/M/P note only) · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.14.1 · Base 2.4 §5.2.13–5.2.13.1.1 · Base 2.4 §5.2.13.1.6 · Base 2.4 §5.2.26–5.2.27

Format, Sanitize and Sanitize Namespace have Admin opcodes 80h,84h and 8Ch. Discovery submits Identify (06h) and Get Log Page (02h), with LID 05h selecting the command table. Do not put 8Ch in LID or treat support for Get Log Page itself as support for every log or management command.

2. Query sequence and interpretation

Establish query access and log support, read the correct entry, then check method, parameters and target state when CSUPP=1. Discovery requires no sanitize initiation. Before actual execution, additionally check active NSID, protection, sanitize state, concurrency and pending-firmware restrictions.

Successful Identify/Get Log Page provides capability evidence. CSUPP=1 for 8Ch establishes advertised Sanitize Namespace support, not current eligibility of NSID 7 or completed erasure.

3. Handle missing or inconsistent evidence

An unsupported LID 05h generally causes Invalid Log Page (1/09h), leaving no valid CSUPP result; it is not CSUPP=0. An unsupported submitted opcode and an invalid SANACT in a supported command are separate conditions using 0/01h and 0/02h respectively.

Compare the same controller, command-set context and configuration period. With CSUPP=1, exclude invalid parameters/state before alleging inconsistency. CSUPP=0 with valid successful execution needs investigation. OWS=1 does not legalize namespace Overwrite.

First confirm a successful LID 05h read and the Admin entry for 8Ch. Selecting 84h, using the wrong offset units or decoding a buffer from a failed query invalidates the support conclusion.

Sources: Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.6 · Base 2.4 §5.2.26–5.2.27 · Base 2.4 §5.1.1, 5.2.11 · NVM Command Set 1.3 §4.1.2 · Base 2.4 §5.2.13.1.14.2.7–5.2.13.1.14.2.8 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §3.1.3.4 (Figure 28 PCIe I/O-controller rows and O/M/P note only) · Base 2.4 §5.2.13–5.2.13.1.1 · Base 2.4 §5.2.14.1

Source locations for this question

Back to questions

Q119 How do Format, secure erase and the two sanitize targets differ?

Follow the explanation

Format changes media format and can request secure erase; Sanitize removes target user data rather than serving as an ordinary format change.

1. What differs

Format scope is selected by FNA/SES/NSID; subsystem sanitize covers its defined user-data locations and namespace sanitize its selected target.

Format SES0 omits secure erase,1 requests user-data erase and 2 cryptographic erase. Sanitize uses SANACT; namespace sanitization only supports Crypto Erase.

2. How to choose and verify

Check OACS, FNA, SANICAP, namespace state and formats; the shared name Crypto Erase does not imply identical command scope.

Choose based on format change, target and required method. Sanitizing each namespace is not equivalent to covering every subsystem user-data location.

Format completion follows media formatting; successful Sanitize initiation still requires LID 81h monitoring.

3. Conditions that shape the comparison

Invalid formats and unsupported SANACT use their separate statuses, Invalid Format and Invalid Field.

Use Format to select 4 KiB LBAs; erasing one namespace and observing NDE does not establish subsystem GDE.

Sources: Base 2.4 §5.2.26–5.2.27 · Base 2.4 §8.1.27.1–8.1.27.5 · NVM Command Set 1.3 §4.1.7, 5.12 · Base 2.4 §5.1.1, 5.2.11 · NVM Command Set 1.3 §4.1.2 · Base 2.4 §5.2.13.1.14.2.7–5.2.13.1.14.2.8 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Back to questions

Q120 How are Format data format, metadata, PI and SES selected?

PI: Protection Information

Follow the explanation

Format selection determines I/O data and metadata layout; mismatches invalidate subsequent buffers and protection information.

1. Prepare the operation

The selection configures namespaces in the format scope rather than only this command’s transfer.

Read LBAF/FLBAS, MC, DPC, DPS and applicable NVM format extensions, plus LBAFEE.

LBAFL plus enabled LBAFU select format; MSET selects extended or separate metadata, PI selects 0–3, and current NVM PIL must be 0. SES independently selects secure erase.

2. Sequence and completion conditions

Select an advertised format and verify metadata/PI compatibility. For hypothetical LBAF2 with 4096+16 bytes, MSET=1 gives 4112 bytes per extended LBA.

LBA: Logical Block Address

On success FLBAS/DPS reflect the selection; changed logical-block size can alter NSZE/NCAP, requiring fresh reads.

3. Handle unmet conditions

Unsupported formats use Invalid Format; formats disabled by missing LBAFEE use Invalid Namespace or Format. Shared FDP RUHs impose matching-format constraints.

FDP: Flexible Data Placement

Recalculate I/O data/metadata lengths rather than retaining the pre-format layout.

Sources: NVM Command Set 1.3 §4.1.5.1–4.1.5.4 · Base 2.4 §5.2.30.1.15 · Base 2.4 §5.1.1, 5.2.11 · NVM Command Set 1.3 §4.1.2 · Base 2.4 §5.2.13.1.14.2.7–5.2.13.1.14.2.8 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Back to questions

Q121 How are invalid Format parameters and states reported?

Follow the explanation

Rejection can result from unsupported/disabled formats, protection or conflicting operations, requiring different fixes.

1. Distinguish the failure conditions

Compute full format scope before checking protection across all affected namespaces.

Relevant codes are 1/0Ah,0/0Bh,0/20h,0/0Ch and 0/84h respectively.

With I/O being processed for an affected namespace, Format may be aborted, using Command Sequence Error if aborted for that reason; rejection is not universally mandatory.

2. Establish the cause from evidence

Establish preconditions through LBAF, LBAFEE, FNA, protection and concurrent operations.

Isolate one defect per negative test, keeping NSID, protection and concurrency valid for an unsupported-LBAF test.

3. Outcome and follow-up checks

Rejection does not establish a format change; re-read configuration rather than treating failure as successful execution.

Tests must distinguish shall/should/may and permitted selection among simultaneous errors.

First check whether multiple defects make an exact-status assertion ambiguous.

Sources: Base 2.4 §4.2.3 · Base 2.4 §5.2.30.1.38, 8.1.18 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.1.1, 5.2.11 · NVM Command Set 1.3 §4.1.2 · Base 2.4 §5.2.13.1.14.2.7–5.2.13.1.14.2.8 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Back to questions

Q122 Which Admin operations can continue during Format?

Follow the explanation

Hosts still need status, notifications and queue management; Format does not universally block all Admin commands.

1. Mechanism and scope

Restrictions depend on affected namespaces and Figure 144 command/log conditions.

Examples include Abort, AER, queue management, Identify, Get Features, selected logs and Keep Alive; Namespace Write Protection Config is excluded from allowed Set Features.

2. Understand it through actions and results

Establish support first; the allowed-during-Format list does not enable unsupported optional commands.

Apply Figure 144 per entry: error-log LBA returns zero and only Controller DST should be allowed. Get Log permission does not extend to every LID.

LBA: Logical Block Address

Permitted queries return state without establishing Format completion.

3. Avoid a misleading conclusion

Unlisted Admin commands affecting the target may be aborted and should use Format In Progress for that reason; preexisting conflicting Admin work can instead cause Format sequence error.

Verify command permission, LID restrictions and returned fields separately.

Sources: Base 2.4 §5.1.1–5.1.2 (PCIe commands) · Base 2.4 §5.1.1, 5.2.11 · NVM Command Set 1.3 §4.1.2 · Base 2.4 §5.2.13.1.14.2.7–5.2.13.1.14.2.8 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Back to questions

Q123 How is interrupted Format assessed after reset or power loss?

Follow the explanation

Lost completion means unknown outcome, not guaranteed non-execution or success; reconstruct it from current state and events.

1. Identify the trigger and affected objects

Inspect all originally affected namespaces and their access through other controllers.

Read FLBAS, DPS, NSZE/NCAP, supported FPI and PEL Format Completion.

2. State changes and recovery

FNVMS describes formatting outcome while INFO records a reported status; INFO=0 without a CQE is not proof of success.

Recover access, preserve events and re-read format/usability before resuming I/O; do not assume the old format when completion remains uncertain.

Configure buffers/PI after establishing current format and completion; any new Format must use current capability and scope.

3. Checks across reset or power loss

Trigger	Effect on this operation or state
What survives or continues after Controller Reset?	Controller Reset ends the old command channel. Re-read format, FPI and available Format Completion events after recovery; reset proves neither format success nor rollback.
What survives or continues after NVM Subsystem Reset?	After subsystem reset, recover access and inspect namespaces in the original format scope; one controller’s recovery does not establish all namespace outcomes.
What survives or continues after a power cycle?	Without trustworthy successful completion before power interruption, reassess format and usability and, if needed, perform a valid new Format. Missing success does not imply old data survived.

4. Verify retention and recovery

Reset/power cycle do not roll back Format or guarantee old-data survival.

Link the last trustworthy pre-reset evidence to the first recovered snapshot and mark the observation gap.

First establish whether a trustworthy Format success CQE exists; do not infer it solely from INFO=0.

Sources: Base 2.4 §3.7.1–3.7.4 · NVM Command Set 1.3 §4.1.5.1–4.1.5.4 · Base 2.4 §5.1.1, 5.2.11 · NVM Command Set 1.3 §4.1.2 · Base 2.4 §5.2.13.1.14.2.7–5.2.13.1.14.2.8 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Back to questions

Q124 Which namespace data must be refreshed after Format?

Follow the explanation

Format changes I/O interpretation, requiring refreshed namespace caches rather than old block/PI settings.

1. Prepare the operation

Refresh format and capacity for affected namespaces; Format is not namespace creation/deletion and does not inherently assign a new NSID.

Query namespace and NVM-specific structures for FLBAS, DPS, LBAF, NSZE, NCAP and FPI.

FLBAS reports active format/metadata transfer, DPS protection settings and NSZE/NCAP counts in new logical blocks.

2. Sequence and completion conditions

Wait for Format success, refresh Identify and recalculate address/buffer layout, coordinating other accessors.

Readback must reflect the request; block-size changes can change counts, so identical counts are not a valid universal capacity test.

3. Handle unmet conditions

For old-format readback after success, exclude wrong namespace, stale caching and mistaken scope.

When changing 512-byte to 4096-byte LBAs, compare byte capacity under allowed behavior rather than block counts alone.

Sources: NVM Command Set 1.3 §4.1.5.1–4.1.5.4 · NVM Command Set 1.3 §4.1.2 · Base 2.4 §5.2.13.1.5 · Base 2.4 §5.1.1, 5.2.11 · Base 2.4 §5.2.13.1.14.2.7–5.2.13.1.14.2.8 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Back to questions

Q125 How are Format failures checked using CQE, Error Log and PEL?

Follow the explanation

Distinguish validation rejection from failure after formatting began, which may already have changed data.

1. Preserve the evidence first

Evidence must match the same Format and scope, not a neighboring namespace operation.

Preserve SCT/SC/M/DNR and PEL support/validity.

SCT: Status Code Type
DNR: Do Not Retry, a completion retry indication

Correlate Error Log by IDs/count; Format Start preserves parameters and Completion carries FNVMS/INFO.

2. Work through the possible causes

First establish whether execution began and whether corresponding Start/Completion events exist.

Read the CQE, additional information indicated by M, then PEL/current Identify; do not force one-to-one entries across all sources.

3. Connect observations to specification conditions

A diagnosis establishes failure cause and current usability; retain uncertainty rather than assuming rollback.

Simultaneous faults may permit different statuses; INFO=0 can mean no CQE, requiring FNVMS interpretation.

Compare parameters, result and current format to detect inconsistent controller or host interpretation.

4. Check notifications and log records separately

Re-read namespace format/capacity and changed lists after success. Read the complete conditions in this volume

With supported PEL events, Format Start 07h records the request and Completion 08h the outcome. Read the complete conditions in this volume

Sources: Base 2.4 §5.2.13.1.2 · Base 2.4 §4.2.3 · Base 2.4 §5.1.1, 5.2.11 · NVM Command Set 1.3 §4.1.2 · Base 2.4 §5.2.13.1.14.2.7–5.2.13.1.14.2.8 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Back to questions

Q126 How does SANICAP advertise sanitize methods?

Follow the explanation

SANICAP advertises individual methods and extensions, not a Boolean enabling every sanitize action.

1. Establish the source and scope

CES/BES/OWS advertise subsystem methods; namespace sanitization has separate support and only Crypto Erase in this revision.

Read SANICAP and cross-check opcodes 84h/8Ch and LID 81h support.

2. Fields, units and worked interpretation

CES/BES/OWS select method support; no-deallocate attributes govern NDAS and VERS/NVERS govern verification for the two target types.

Match the required method to its bit before SANACT selection; BES alone does not authorize Overwrite.

Valid initiation succeeds with status updated; supported capability does not guarantee every background operation succeeds.

3. Conditions that change the interpretation

A supported command with unsupported SANACT must return Invalid Field.

Controllers in the same subsystem must advertise consistent supported sanitize types for the corresponding command.

Sources: Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.26–5.2.27 · Base 2.4 §5.2.13.1.38 · Base 2.4 §8.1.27.1–8.1.27.5 · Base 2.4 §5.2.13.1.14.2.9–5.2.13.1.14.2.10 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Back to questions

Q127 How do NDAS, overwrite pattern, passes and inversion work?

Follow the explanation

Overwrite fields select pattern/passes while NDAS controls allocation release; erasure and deallocation are distinct.

1. Establish the source and scope

These overwrite/NDAS fields belong to subsystem Sanitize, not the namespace command layout.

Check OWS, no-deallocate inhibition/media-modification attributes and FID 17h.NODRM.

FID: Feature Identifier

2. Fields, units and worked interpretation

SANACT3 selects Overwrite; OVRPAT is 32-bit, OWPASS0 means 16 passes and 1–15 their literal count; OIPBP1 inverts between passes.

With patternAAAAAAAAh, two passes and inversion, the patterns areAAAAAAAAh then 55555555h; choose NDAS separately.

After completion inspect SOS, completed passes and GDE; deallocated reads follow deallocation rules rather than guaranteeing the final pattern.

3. Conditions that change the interpretation

With inhibited NDAS, NODRM0 rejects with Invalid Field; warning mode permits processing with unexpected-deallocation reporting. Non-overwrite actions ignore overwrite fields as defined.

Compare request fields and logged SCDW10/outcome; OWPASS0 does not mean zero work.

Sources: Base 2.4 §5.2.30.1.16 · NVM Command Set 1.3 §4.1.7, 5.12 · Base 2.4 §5.2.26–5.2.27 · Base 2.4 §5.2.13.1.38 · Base 2.4 §8.1.27.1–8.1.27.5 · Base 2.4 §5.2.13.1.14.2.9–5.2.13.1.14.2.10 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Back to questions

Q128 How are progress, status, state and erased-data flags interpreted together?

Follow the explanation

Progress, outcome, state and continued erased-data condition answer different questions; neitherFFFFh nor GDE1 alone proves full completion.

1. Establish the source and scope

LID 81h selects subsystem or namespace using NSID; NDE does not substitute for subsystem GDE.

Check sanitize/verification support and read a consistent snapshot for the same target.

2. Fields, units and worked interpretation

SPROG/65536 gives applicable-phase progress, SOS outcome/progress category, SANS state, and GDE/NDE the erased condition affected by later writes.

Read SOS, identify the active SANS phase, then interpret SPROG.

SPROG8000h indicates 50% in an applicable processing phase; FFFFh also appears outside processing or during verification and is not standalone success.

3. Conditions that change the interpretation

Invalid targets and namespace queries during subsystem sanitization have distinct Invalid Namespace/Format and Sanitize In Progress conditions.

Match SCDW10 to the request and consider subsequent writes clearing GDE/NDE rather than mistaking an old result for the current operation.

Sources: NVM Command Set 1.3 §4.1.7, 5.12 · Base 2.4 §5.2.26–5.2.27 · Base 2.4 §5.2.13.1.38 · Base 2.4 §8.1.27.1–8.1.27.5 · Base 2.4 §5.2.13.1.14.2.9–5.2.13.1.14.2.10 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Back to questions

Q129 Which commands are permitted during subsystem sanitization?

Follow the explanation

Sanitization restricts user-data access while preserving essential management; permissions apply to commands, options and logs.

1. Mechanism and scope

Restrictions apply across subsystem controllers; another controller is not a bypass.

Identify, AER, Get Features, queue management and selected logs remain available. PEL/vendor logs and self-test are prohibited; Error Log LBA returns zero.

2. Understand it through actions and results

Use Figure 144, the sanitize state machine and NVM Figures 200/201.

Apply state, command and LID restrictions; Flush and media-verification reads have explicit exceptions to ordinary I/O blocking.

Allowed commands complete while prohibited commands are rejected and sanitization continues; avoid excessively frequent polling.

3. Avoid a misleading conclusion

In-progress rejection generally uses Sanitize In Progress; failure-state processing follows its command-specific rules.

Verify restrictions across controllers and permitted logs' sanitization of user-data fields.

Sources: Base 2.4 §5.1.1–5.1.2 (PCIe commands) · NVM Command Set 1.3 §4.1.7, 5.12 · Base 2.4 §5.2.26–5.2.27 · Base 2.4 §5.2.13.1.38 · Base 2.4 §8.1.27.1–8.1.27.5 · Base 2.4 §5.2.13.1.14.2.9–5.2.13.1.14.2.10 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Back to questions

Q130 Does sanitization continue across reset or power loss?

Follow the explanation

Reset or power cycling must not provide an escape from sanitization; background processing continues across them.

1. Identify the trigger and affected objects

What persists is the target operation/state machine, not old Admin Queues or AER requests.

After recovering access, inspect target NSID, SOS, SANS, SCDW10 and MVCNCLD.

2. State changes and recovery

MVCNCLD reports cancelled media verification under specified transport/subsystem-reset conditions, not cancelled sanitization.

Preserve pre-reset state, re-read the same target and identify processing/deallocation/completion before attempting another operation.

Continuing or completed operation can be correct; no progress while unpowered is expected, but forgetting the operation is not.

3. Checks across reset or power loss

Trigger	Effect on this operation or state
What survives or continues after Controller Reset?	Background sanitization continues through Controller Level Reset. Re-read target LID 81h after recovery. Some reset sources cancel media verification and set MVCNCLD without cancelling the entire sanitize operation.
What survives or continues after NVM Subsystem Reset?	Subsystem reset does not abort sanitization. Preserve operation/log state and check MVCNCLD and post-verification deallocation when verification was requested.
What survives or continues after a power cycle?	Processing cannot occur without power, but sanitization continues from retained state after power returns. Inspect SOS/SANS and progress; SPROG=FFFFh alone is not success.

4. Verify retention and recovery

A new initiation during processing can be rejected as Sanitize In Progress without implying reset damage.

Verify parameter/target/state continuity separately from renewed AER and query setup.

First ensure the post-reset query addresses the original target.

Sources: Base 2.4 §3.7.1–3.7.4 · Base 2.4 §5.2.26–5.2.27 · Base 2.4 §5.2.13.1.38 · Base 2.4 §8.1.27.1–8.1.27.5 · Base 2.4 §5.2.13.1.14.2.9–5.2.13.1.14.2.10 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Back to questions

Q131 How do success, failure and failure mode differ in the log?

Follow the explanation

Outcome and current state differ: leaving failure mode can return to Idle while the latest sanitize outcome remains failed.

1. Preserve the evidence first

Use SOS/SANS for one target; namespace failure is not the subsystem’s last-operation result.

Read LID 81h and applicable FAILS/MVCNCLD to establish the failure stage.

SOS001b means sanitized,010b sanitizing,011b failed and 100b sanitized with unexpected deallocation; SANS identifies the actual state.

2. Work through the possible causes

First inspect SANS to distinguish current failure mode from historical failure outcome.

Inspect outcome and current restrictions; Idle with failed SOS can follow valid Exit Failure Mode.

3. Connect observations to specification conditions

Neither progress alone nor the initiation CQE establishes the final background outcome.

Restricted and Unrestricted Failure allow different recovery actions despite both reporting failure.

Correlate SOS, SANS, original AUSE and recovery requests to identify invalid transitions.

Sources: Base 2.4 §5.2.26–5.2.27 · Base 2.4 §5.2.13.1.38 · Base 2.4 §8.1.27.1–8.1.27.5 · Base 2.4 §5.2.13.1.14.2.9–5.2.13.1.14.2.10 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Back to questions

Q132 What does Exit Failure Mode accomplish?

Follow the explanation

Where permitted, Exit Failure Mode releases failure-state restrictions; it neither finishes erasure nor converts failure into success.

1. Mechanism and scope

The action applies to the selected subsystem or namespace target.

SANACT001b requests Exit Failure Mode, not a new erasure operation.

2. Understand it through actions and results

Read SANS and original AUSE, which selects restricted versus unrestricted processing.

Unrestricted Failure can transition to Idle; Restricted Failure requires a permitted new sanitize operation. The action in Idle is not an error.

Valid exit restores permitted access while SOS can retain failure; exit alone cannot establish GDE/NDE erasure.

3. Avoid a misleading conclusion

Exit is rejected under restricted-failure rules; repeated requests or reset do not bypass them.

Verify both restored state and retained failure history rather than demanding all-zero logs.

Source locations for this question

Back to questions

Q133 When are sanitize AERs and persistent events generated?

Follow the explanation

Notifications announce transitions and PEL retains history; neither is a second completion of the initiating command.

1. When the event exists and who observes it

The initiating controller reports the AER; event parameters and PEL.NSID identify the target.

Establish event/configuration support, outstanding AERs and PEL support.

AET6/LID 81h use AEI01h for completion,02h unexpected deallocation and 03h verification entry; DW1 carries defined target information.

2. Notification, reading and acknowledgment

Record start at initiation, notify verification entry separately and record completion at Idle/failure transitions; read the same target after notification.

Completed notifications and PEL completion can describe failure; inspect SOS/SANS/SSTAT.

3. Evaluate missing notifications or records

Without an AER request no immediate CQE is expected; normal retention/masking rules apply. Do not require PEL reads while prohibited during sanitization.

Correlate event target, initiating command and log state to distinguish notification loss from unfinished processing.

First check AEC, available requests and reporting controller before declaring a missing event.

4. Check notifications and log records separately

State transitions report completed, unexpected-deallocation completion or media-verification entry with LID 81h. Read the complete conditions in this volume

Supported PEL logging records Start 09h on entering processing and Completion 0Ah on entering Idle or either failure state. Read the complete conditions in this volume

Sources: Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.30.1.6 · Base 2.4 §5.2.26–5.2.27 · Base 2.4 §5.2.13.1.38 · Base 2.4 §8.1.27.1–8.1.27.5 · Base 2.4 §5.2.13.1.14.2.9–5.2.13.1.14.2.10 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Back to questions

Q134 How is namespace sanitization targeted and isolated?

Follow the explanation

Namespace Sanitize provides a narrower Crypto Erase target while shared management restrictions remain separate from data isolation.

1. Prepare the operation

NSID selects one active namespace, with restrictions applying across all controllers accessing it.

Check Admin opcode 8Ch CSUPP in LID 05h, then CES and any required NVERS/SPRRS capability; Q118 gives the lookup. Separately establish active namespace, protection and MNSOIP limits before claiming current eligibility.

Use opcode 8Ch/SANACT100b; PREQ is CDW10 bit 4 rather than subsystem bit 11. Query that NSID’s LID 81h/NDE.

2. Sequence and completion conditions

Snapshot target and non-target baselines, initiate and monitor the target, then verify erasure and preservation of non-target data.

Target NDE may become 1; sanitizing all namespaces still does not establish GDE because subsystem scope includes other locations.

3. Handle unmet conditions

Zero, broadcast, inactive or deleting namespaces use Invalid Namespace/Format; protection uses Namespace is Write Protected.

Validate non-target data, target I/O restrictions and shared firmware restrictions separately.

Sources: Base 2.4 §5.1.1–5.1.2 (PCIe commands) · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.2.1 · Base 2.4 §5.2.26–5.2.27 · Base 2.4 §5.2.13.1.38 · Base 2.4 §8.1.27.1–8.1.27.5 · Base 2.4 §5.2.13.1.14.2.9–5.2.13.1.14.2.10 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §5.2.13.1.6

Source locations for this question

Back to questions

Q135 How are invalid or unsupported namespace sanitize requests handled?

Follow the explanation

Unsupported command, invalid target/action and exhausted concurrency are distinct failure causes.

1. Distinguish the failure conditions

Check target and subsystem sanitize state; subsystem failure can block a new namespace operation.

Namespace SANACT supports Crypto Erase and defined state-management actions;010b/011b are reserved.

Invalid targets use Invalid Namespace/Format, actions Invalid Field and over-limit requests their named concurrency status. Figure 104 lists 3Ch while Figure 455 lists 12h: the source conflict prevents treating either as an undisputed sole acceptance value.

2. Establish the cause from evidence

Read CSUPP for Admin opcode 8Ch in LID 05h to establish command support. Then check SANICAP for the method, namespace lists and write protection for target state, and LID 81h.MNSOIP for concurrency limits. This connects support to current execution conditions; Q118 gives the full lookup.

Establish valid support, then isolate target, protection, action and concurrency negative tests with state snapshots.

3. Outcome and follow-up checks

An unsuccessful initiation must not start sanitization, alter target Sanitize Status or alter user data for that command.

Verify both status and absence of operation/data changes for rejected requests.

First isolate the failed condition; preserve both source locations for the conflicting concurrency code.

Sources: Base 2.4 §4.2.3 · Base 2.4 §3.2.1 · Base 2.4 §5.2.30.1.38, 8.1.18 · Base 2.4 §5.2.26–5.2.27 · Base 2.4 §5.2.13.1.38 · Base 2.4 §8.1.27.1–8.1.27.5 · Base 2.4 §5.2.13.1.14.2.9–5.2.13.1.14.2.10 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §5.2.13.1.6

Source locations for this question

Back to questions

Shared rules linked from the answers

Each shared mechanism is explained in full once in this volume. Use browser Back to return to the question; explicit command or feature exceptions take precedence.

Shared conditions for this topic · Are Error Information or other logs updated?

Re-read namespace format/capacity and changed lists after success. For errors use CQE.More and Error Information; a successful Get Log does not substitute for Format completion.

Shared conditions for this topic · Is it recorded in the Persistent Event Log?

With supported PEL events, Format Start 07h records the request and Completion 08h the outcome. Read FNVMS with INFO; INFO can be zero when no Format CQE was reported and does not alone prove success.

Shared conditions for this topic · Is an asynchronous event generated?

State transitions report completed, unexpected-deallocation completion or media-verification entry with LID 81h. For Admin-SQ initiation, only the initiating controller reports the event; inspect the log for actual outcome.

Shared conditions for this topic · Is it recorded in the Persistent Event Log?

Supported PEL logging records Start 09h on entering processing and Completion 0Ah on entering Idle or either failure state. Completion includes failures; NSID distinguishes subsystem and namespace targets.

Source locations and existing figure guides

Base printed page = PDF page−26; the other two use identical numbers. Locations follow the supplied PDF body and retain figure numbers. Shared pages contribute only the relevant definitions, excluding Fabrics and PCIe link/packet content.

Base 2.4 · §3.1.3.4 (Figure 28 PCIe I/O-controller rows and O/M/P note only)
Printed pages 45–47 · PDF 71–73 · Figure 28
Base 2.4 · §3.2.1
Printed pages 78–81 · PDF 104–107
Base 2.4 · §3.7.1–3.7.4
Printed pages 120–124 · PDF 146–150
Base 2.4 · §4.2.3
Printed pages 145–155 · PDF 171–181 · Figure 101–105
Base 2.4 · §5.1.1, 5.2.11
Printed pages 178–179, 206–209 · PDF 204–205, 232–235 · Figure 144, 194–196
Base 2.4 · §5.1.1–5.1.2 (PCIe commands)
Printed pages 178–181 · PDF 204–207 · Figure 144–146
Base 2.4 · §5.2.2
Printed pages 183–190 · PDF 209–216 · Figure 150–156
Base 2.4 · §5.2.2 (PCIe-applicable events)
Printed pages 183–191 · PDF 209–217 · Figure 150–160
Base 2.4 · §5.2.13–5.2.13.1.1
Printed pages 212–218 · PDF 238–244 · Figure 203–211
Base 2.4 · §5.2.13.1.2
Printed pages 218–220 · PDF 244–246 · Figure 212
Base 2.4 · §5.2.13.1.5
Printed pages 226 · PDF 252
Base 2.4 · §5.2.13.1.6
Printed pages 226–229 · PDF 252–255 · Figure 216–217
Base 2.4 · §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Printed pages 244–256, 258, 262–264 · PDF 270–282, 284, 288–290 · Figure 232–244, 246, 252–253
Base 2.4 · §5.2.13.1.14.2.7–5.2.13.1.14.2.8
Printed pages 259–261 · PDF 285–287 · Figure 248–249
Base 2.4 · §5.2.13.1.14.2.9–5.2.13.1.14.2.10
Printed pages 261–262 · PDF 287–288 · Figure 250–251
Base 2.4 · §5.2.13.1.38
Printed pages 313–320 · PDF 339–346 · Figure 312
Base 2.4 · §5.2.14.1
Printed pages 336–340 · PDF 362–366 · Figure 332–337
Base 2.4 · §5.2.14.2.1
Printed pages 340–387 · PDF 366–413 · Figure 338–341
Base 2.4 · §5.2.26–5.2.27
Printed pages 448–454 · PDF 474–480 · Figure 451–455
Base 2.4 · §5.2.30.1.6
Printed pages 466–468 · PDF 492–494 · Figure 474
Base 2.4 · §5.2.30.1.15
Printed pages 475–477 · PDF 501–503 · Figure 491
Base 2.4 · §5.2.30.1.16
Printed pages 477–478 · PDF 503–504 · Figure 492
Base 2.4 · §5.2.30.1.38, 8.1.18
Printed pages 512, 664–666 · PDF 538, 690–692 · Figure 541, 735–737
Base 2.4 · §8.1.27.1–8.1.27.5
Printed pages 711–732 · PDF 737–758 · Figure 770–779
NVM Command Set 1.3 · §4.1.2
Printed pages 62–63 · PDF 62–63 · Figure 91
NVM Command Set 1.3 · §4.1.5.1–4.1.5.4
Printed pages 84–107 · PDF 84–107 · Figure 123–130
NVM Command Set 1.3 · §4.1.7, 5.12
Printed pages 113, 173–175 · PDF 113, 173–175 · Figure 200–201

When you need a field guide

Existing figure explanations have canonical locations; use these links instead of duplicating the same guide.

Original documents used

NVM Express Base Specification · Revision 2.4 · 2026-07-31
NVM-Express-Base-Specification-Revision-2.4-Ratified-2026.07.31.pdf
NVM Express NVM Command Set Specification · Revision 1.3 · 2026-07-31
NVM-Express-NVM-Command-Set-Specification-Revision-1.3-Ratified-2026.07.31.pdf
NVM Express NVMe over PCIe Transport Specification · Revision 1.4 · 2026-07-31
NVM-Express-NVMe-over-PCIe-Transport-Specification-Revision-1.4-Ratified-2026.07.31.pdf

NVMe Self-Study Bank: Format and sanitize

Three distinct operation paths

Questions in this volume

Q118 How is support for Format, Sanitize and Sanitize Namespace discovered?

1. Select the target and information

Worked lookup: from Sanitize Namespace to CSUPP

2. Query sequence and interpretation

3. Handle missing or inconsistent evidence

Q119 How do Format, secure erase and the two sanitize targets differ?

1. What differs

2. How to choose and verify

3. Conditions that shape the comparison

Q120 How are Format data format, metadata, PI and SES selected?

1. Prepare the operation

2. Sequence and completion conditions

3. Handle unmet conditions

Q121 How are invalid Format parameters and states reported?

1. Distinguish the failure conditions

2. Establish the cause from evidence

3. Outcome and follow-up checks

Q122 Which Admin operations can continue during Format?

1. Mechanism and scope

2. Understand it through actions and results

3. Avoid a misleading conclusion

Q123 How is interrupted Format assessed after reset or power loss?

1. Identify the trigger and affected objects

2. State changes and recovery

3. Checks across reset or power loss

4. Verify retention and recovery

Q124 Which namespace data must be refreshed after Format?

1. Prepare the operation

2. Sequence and completion conditions

3. Handle unmet conditions

Q125 How are Format failures checked using CQE, Error Log and PEL?

1. Preserve the evidence first

2. Work through the possible causes

3. Connect observations to specification conditions

4. Check notifications and log records separately

Q126 How does SANICAP advertise sanitize methods?

1. Establish the source and scope

2. Fields, units and worked interpretation

3. Conditions that change the interpretation

Q127 How do NDAS, overwrite pattern, passes and inversion work?

1. Establish the source and scope

2. Fields, units and worked interpretation

3. Conditions that change the interpretation

Q128 How are progress, status, state and erased-data flags interpreted together?

1. Establish the source and scope

2. Fields, units and worked interpretation

3. Conditions that change the interpretation

Q129 Which commands are permitted during subsystem sanitization?

1. Mechanism and scope

2. Understand it through actions and results

3. Avoid a misleading conclusion

Q130 Does sanitization continue across reset or power loss?

1. Identify the trigger and affected objects

2. State changes and recovery

3. Checks across reset or power loss

4. Verify retention and recovery

Q131 How do success, failure and failure mode differ in the log?

1. Preserve the evidence first

2. Work through the possible causes

3. Connect observations to specification conditions

Q132 What does Exit Failure Mode accomplish?

1. Mechanism and scope

2. Understand it through actions and results

3. Avoid a misleading conclusion

Q133 When are sanitize AERs and persistent events generated?

1. When the event exists and who observes it

2. Notification, reading and acknowledgment

3. Evaluate missing notifications or records

4. Check notifications and log records separately

Q134 How is namespace sanitization targeted and isolated?

1. Prepare the operation

2. Sequence and completion conditions

3. Handle unmet conditions

Q135 How are invalid or unsupported namespace sanitize requests handled?

1. Distinguish the failure conditions

2. Establish the cause from evidence

3. Outcome and follow-up checks