NVMe · Q1–328

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

Q157–Q173

Namespace management, attachment and protection

Creation, attachment and write protection are separate states connected through a namespace 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

Check existence, access and writability separately

Creation does not automatically attach a namespace.

Question	Evidence	Next step
Does it exist?	Allocated inventory and returned NSID	Check format/capacity
Is it attached here?	Active and attachment lists	Check readiness/path
Is writing allowed?	Capability, control and state	Apply command restrictions

NSID: Namespace Identifier

Worked interpretation: Namespace 2 absent from A’s active list may still exist and be attached to B.

Sources: Base 2.4 §5.2.24–5.2.25, 8.1.17–8.1.17.2 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.8 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §5.2.30.1.38, 8.1.18

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

Q157 · How are namespace management and attachment supported?
Q158 · How are size, capacity, format and thin provisioning selected?
Q159 · How are namespace-creation resource and parameter errors reported?
Q160 · How does creation change the allocated namespace list?
Q161 · How are controllers selected for attachment changes?
Q162 · How are active and controller lists cross-checked?
Q163 · How are attachment relationship errors reported?
Q164 · What happens to outstanding commands during detach?
Q165 · How are commands handled after namespace detach?
Q166 · How are nonexistent or attached namespace deletions handled?
Q167 · Which events and logs follow namespace changes?
Q168 · How does changed-namespace overflow work?
Q169 · Do namespace configuration and attachment survive resets?
Q170 · How do private and shared namespaces differ?
Q171 · How do write-protection modes and entry controls differ?
Q172 · How does write protection persist across reset and power?
Q173 · How does protection affect format, sanitize and namespace management?

Q157 How are namespace management and attachment supported?

Follow the explanation

Management creates/deletes namespaces; attachment controls controller access. The capabilities are related but not equivalent.

1. Select the target and information

Allocation is subsystem inventory; active access is controller-specific.

NMS1 requires both commands; NMS0 can still support attachment alone, discoverable through Command Effects.

Opcodes 0Dh and 15h have different SEL action definitions.

2. Query sequence and interpretation

Establish command support, enumerate objects and construct the intended operation.

NMS entails both command capabilities; attachment-only support does not authorize creation.

3. Handle missing or inconsistent evidence

Distinguish unsupported opcode from unsupported Restore Default action, which uses Invalid Field.

Cross-check OACS, CSUPP and valid behavior.

First check the mistaken implication that NMS0 forbids attachment.

Sources: Base 2.4 §5.2.13.1.6 · Base 2.4 §5.2.24–5.2.25, 8.1.17–8.1.17.2 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §5.2.13.1.14.2.6 · 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

Q158 How are size, capacity, format and thin provisioning selected?

Follow the explanation

NSZE defines address range and NCAP allocatable logical blocks, both in the selected format’s units.

1. Establish the source and scope

Creation consumes selected resources without attaching the new namespace.

Inspect common capabilities, format list, thin provisioning, unallocated capacity and reported granularity.

2. Fields, units and worked interpretation

Set NSZE/NCAP/FLBAS/DPS/NMIC and resource IDs. NCAP cannot exceed NSZE; smaller capacity requires thin-provisioning support.

Select format before conversion:1000×4 KiB=4000 KiB user capacity, while physical allocation can be larger.

Successful creation returns NSID in DW0 and formats the namespace; verify before attachment.

3. Conditions that change the interpretation

Invalid format, unsupported thin provisioning, capacity shortage and ID exhaustion are distinct.

Compare requested block counts/format with NSZE/NCAP/NVMCAP using their distinct units.

Sources: NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.8 · NVM Command Set 1.3 §4.1.5.1–4.1.5.4 · Base 2.4 §5.2.24–5.2.25, 8.1.17–8.1.17.2 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §5.2.13.1.14.2.6 · 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

Q159 How are namespace-creation resource and parameter errors reported?

Follow the explanation

Distinguish capacity, identifier count, format and resource mapping before choosing a remedy.

1. Distinguish the failure conditions

Capacity is evaluated in the selected resource pool, not unrelated groups.

Distinct codes are capacity 1/15h, identifier 1/16h, format 1/0Ah and thin provisioning 1/1Bh.

Missing preferred granularity can waste allocation but must not alone reject an otherwise valid create.

2. Establish the cause from evidence

Inspect capacity, applicable namespace limits, formats/granularity and resource lists.

Isolate parameters; for insufficient capacity inspect CSINFO’s required unallocated bytes.

3. Outcome and follow-up checks

Only successful Create DW0 contains the created NSID.

Distinguish invalid format from insufficient allocation using consistent quantities.

First decode SCT/SC before choosing the resource to inspect.

SCT: Status Code Type

Sources: NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.8 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.24–5.2.25, 8.1.17–8.1.17.2 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §5.2.13.1.14.2.6 · 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

Q160 How does creation change the allocated namespace list?

Follow the explanation

Allocated means existence; active means access through a controller. Creation establishes allocation first.

1. Prepare the operation

Allocated inventory and controller-specific active lists are distinct.

Query CNS 10h and the new namespace; CNS 02h verifies later attachment.

CNS: Controller or Namespace Structure, selecting Identify data

Create returns a controller-selected ID, not a guaranteed host-predicted sequence.

2. Sequence and completion conditions

Snapshot inventory, await success and enumerate again to identify the new object.

The new ID is allocated but creation does not automatically attach it.

3. Handle unmet conditions

Continue enumeration when lists are longer than one response.

Correlate returned ID, inventory and attributes rather than count alone.

Sources: Base 2.4 §3.2.1 · Base 2.4 §5.2.24–5.2.25, 8.1.17–8.1.17.2 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §5.2.13.1.14.2.6 · 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

Q161 How are controllers selected for attachment changes?

Follow the explanation

Attachment changes access relationships without creating/deleting or reformatting the namespace.

1. Prepare the operation

NSID selects the namespace and the payload Controller List selects controllers.

Check allocation, sharing, controller IDs, command-set support and attachment limits.

SEL 0 attaches and 1 detaches using a 4096-byte list of controller IDs, not namespace IDs.

2. Sequence and completion conditions

Submit a valid list and verify each targeted controller and namespace relationship afterward.

Successful attachment change preserves namespace allocation.

3. Handle unmet conditions

Invalid/admin-controller list entries and unsupported/disabled command sets have separate statuses.

CSINFO identifies the first failing entry offset; processing stops there, without a universal all-or-nothing rollback guarantee.

Sources: Base 2.4 §5.2.24–5.2.25, 8.1.17–8.1.17.2 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §5.2.13.1.14.2.6 · 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

Q162 How are active and controller lists cross-checked?

Follow the explanation

View the relationship from both controller and namespace to detect one-sided updates.

1. Prepare the operation

An active list belongs to one controller, not the full subsystem.

Use applicable active/controller-list queries such as CNS 02h/12h with verified identity.

Preserve IDs and pagination markers to avoid missing the target.

2. Sequence and completion conditions

Successful attach appears in both views; detach removes it from both.

If namespace 7 attaches toA thenB, B’s active list contains 7 and the namespace’s controller list containsA/B.

3. Handle unmet conditions

Concurrent management can make snapshots temporally inconsistent; stabilize before diagnosing contradiction.

Allocation persists across attachment-only changes.

Sources: Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §5.2.24–5.2.25, 8.1.17–8.1.17.2 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.6 · 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

Q163 How are attachment relationship errors reported?

Follow the explanation

Relationship/list errors do not imply namespace-data damage.

1. Distinguish the failure conditions

Evaluate each list entry against its state; earlier entries may have been processed before failure.

Codes distinguish already-attached 1/18h, private 1/19h, not-attached 1/1Ah and invalid-list 1/1Ch.

A second attachment of an already attached private namespace is rejected for privacy, not capacity.

2. Establish the cause from evidence

Inspect current attachment, sharing and target capabilities.

Isolate the error and reread affected relationships and first-failure position.

3. Outcome and follow-up checks

Valid operations change relationships; errors stop processing further list entries.

Correlate status/offset and pre/post lists instead of assuming global rollback.

First check sharing mode and existing attachment.

Sources: Base 2.4 §4.2.3 · Base 2.4 §5.2.24–5.2.25, 8.1.17–8.1.17.2 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §5.2.13.1.14.2.6 · 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

Q164 What happens to outstanding commands during detach?

Follow the explanation

Detach invalidates controller access; quiescing first helps hosts, but outstanding-command behavior remains specified.

1. Mechanism and scope

Only specified relationships change; other attached controllers remain attached.

Base 8.1.17 applies inactive-NSID rules to outstanding and later commands, subject to command exceptions.

2. Understand it through actions and results

Preserve outstanding IDs, namespace and detach completion timing.

Quiesce, synchronize and drain where possible before detach; race tests must retain precise ordering.

Detach removes the relationship without duplicate completions; outstanding work follows inactive rules.

3. Avoid a misleading conclusion

Generic inactive handling uses Invalid Field, with explicit command exceptions.

Check timing classification and premature buffer reclamation.

Sources: Base 2.4 §4.1.1 · Base 2.4 §3.2.1 · Base 2.4 §5.2.24–5.2.25, 8.1.17–8.1.17.2 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §5.2.13.1.14.2.6 · 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

Q165 How are commands handled after namespace detach?

Follow the explanation

Detach makes an ID inactive on that controller without deleting it from the subsystem.

1. Distinguish the failure conditions

The same namespace can remain active through another controller.

Figure 93 uses Invalid Field for inactive IDs by default; Identify and other management selectors have their own rules.

Successful allocated-object Identify does not disprove detach; inactive and invalid IDs differ.

2. Establish the cause from evidence

Inspect controller-active, allocated and namespace-controller lists.

After completion, compare the detached and still-attached paths with other conditions fixed.

3. Outcome and follow-up checks

Allocation does not authorize normal active data access, while allocated-object management queries can remain valid.

Apply the specific opcode/CNS rule, not NSID alone.

First distinguish ordinary I/O from permitted inactive-object queries.

Source locations for this question

Back to questions

Q166 How are nonexistent or attached namespace deletions handled?

Follow the explanation

Correct the premise that attached namespaces cannot be deleted: prior detach is recommended, and deletion itself removes all attachments.

1. Distinguish the failure conditions

Deletion removes the object, not merely one access path.

SEL 1 deletes; NSID selects an existing namespace andFFFFFFFFh all. Delete-all with no valid namespaces succeeds.

Specific nonexistent targets follow NSID/command errors, unlike empty delete-all; protection/sanitization impose additional restrictions.

2. Establish the cause from evidence

Check allocation, protection, background work and scope before individual/all deletion.

Quiesce, preferably detach all accessors, delete and refresh inventory/active lists.

3. Outcome and follow-up checks

Success removes object and attachment; the numeric NSID may later be reused.

Verify actual inventory removal rather than only detachment.

First inspect broadcast NSID before judging empty-inventory behavior.

Sources: Base 2.4 §4.1.1 · Base 2.4 §3.2.1 · Base 2.4 §5.2.30.1.38, 8.1.18 · Base 2.4 §5.2.24–5.2.25, 8.1.17–8.1.17.2 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §5.2.13.1.14.2.6 · 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

Q167 Which events and logs follow namespace changes?

Follow the explanation

Notifications invalidate host caches, changed lists identify changes and Identify describes current configuration.

1. When the event exists and who observes it

Create/delete change inventory; attach/detach change controller-active membership.

Check attached/allocated notice support, enablement and available requests.

LID 04h/1Ch identify attached/allocated changes; Identify and defined PEL management events serve different purposes.

LID: Log Page Identifier

2. Notification, reading and acknowledgment

Process affected-controller notices, preserve lists and refresh Identify after management completion.

The Admin Delete recipient omits its own deletion notice while other eligible controllers report; equal counts are not required.

3. Evaluate missing notifications or records

Disabled/masked/acknowledged events change observable AERs; command success alone does not prove a missing event defect.

Correlate origin, affected lists and per-controller AEC on a timeline.

First check whether the observer is the Admin Delete recipient.

4. Check notifications and log records separately

Create/delete affect allocated inventory; attach/detach affect controller active lists. Read the complete conditions in this volume

Identify lists establish current allocation/attachment; changed lists 04h/1Ch identify changes rather than complete state. Read the complete conditions in this volume

Supported Change Namespace 06h records defined management changes; do not treat attachment as creation/deletion. 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.13.1.5 · Base 2.4 §5.2.13.1.14.2.6 · Base 2.4 §5.2.24–5.2.25, 8.1.17–8.1.17.2 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · 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

Q168 How does changed-namespace overflow work?

Follow the explanation

Overflow requests a full relevant rescan instead of trusting an incomplete list.

1. Establish the source and scope

LID 04h concerns attached changes for that controller, not universal subsystem history.

LID: Log Page Identifier

Apply the fixed 1024-entry layout and read/clear rules.

2. Fields, units and worked interpretation

More than 1024 changed namespaces yieldsFFFFFFFFh first and zeros in remaining entries.

Detect the marker, enumerate and refresh properties rather than treating it as an object ID.

Full rescan restores current state; repeated 04h reads are not historical pagination.

3. Conditions that change the interpretation

A short transfer is distinct from log overflow.

Validate rescan cache against current Identify state.

Sources: Base 2.4 §5.2.13.1.5 · Base 2.4 §5.2.13–5.2.13.1.1 · Base 2.4 §5.2.24–5.2.25, 8.1.17–8.1.17.2 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §5.2.13.1.14.2.6 · 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

Q169 Do namespace configuration and attachment survive resets?

Follow the explanation

Namespaces are persistent configuration, separate from recreated queues.

1. Identify the trigger and affected objects

Completed configuration persists; interrupted commands require state discovery.

Preserve global identity, NSID, format and attachment for comparison.

2. State changes and recovery

Resets/power cycle are not the explicit Restore Default Namespace Configuration operation.

Recover Admin access, enumerate existing namespaces/attachments, then build queues rather than recreating objects.

Existing configuration becomes accessible again; secondary-controller Offline does not erase attachment.

3. Checks across reset or power loss

Trigger	Effect on this operation or state
What survives or continues after Controller Reset?	Completed configuration/attachment survives reset; command channels reset without deleting namespaces. For interrupted commands, inspect lists rather than assuming rollback.
What survives or continues after NVM Subsystem Reset?	Subsystem reset is not Restore Default Namespace Configuration. Rediscover persisted namespaces/attachments and rebuild queues, accounting for domain scope.
What survives or continues after a power cycle?	Completed namespace configuration/attachments persist. Ordinary/permanent write protection persist; until-power-cycle protection clears on a real power cycle, not all configuration.

4. Verify retention and recovery

Post-reset lists may reflect an operation whose CQE was lost; absence of completion does not prove non-execution.

CQE: Completion Queue Entry

Match persistent identity/properties to avoid NSID-reuse mistakes.

First check whether host recovery itself restored defaults or deleted objects.

Sources: Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.2.1 · Base 2.4 §5.2.24–5.2.25, 8.1.17–8.1.17.2 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §5.2.13.1.14.2.6 · 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

Q170 How do private and shared namespaces differ?

Follow the explanation

Private limits attachment to one controller; shared allows multiple. These describe access topology, not encryption or access permissions.

1. What differs

Multiple paths can address one data object, not separate copies.

NMIC is selected at creation; attachment changes relationships within supported limits.

2. How to choose and verify

Inspect NMIC and actual attachments.

Configure sharing, attach controllers and verify each active list.

Shared permits multiple accessors; private can move fromA toB through detachment but not attach to both simultaneously.

3. Conditions that shape the comparison

Additional attachment of an already attached private namespace uses Namespace Is Private.

Compare identity/data/attachments rather than counting paths as additional capacity.

Sources: NVM Command Set 1.3 §4.1.5.1–4.1.5.4 · Base 2.4 §5.2.24–5.2.25, 8.1.17–8.1.17.2 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §5.2.13.1.14.2.6 · 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

Q171 How do write-protection modes and entry controls differ?

Follow the explanation

Protection modes differ in reversibility; permanent protection is not an ordinary reversible toggle.

1. What differs

WPS is namespace state enforced across attached controllers.

WPS0/1/2/3 select unprotected/ordinary/until-cycle/permanent; only ordinary protection is normally reversible by Set.

2. How to choose and verify

NWPC advertises modes, RPMB WPC gates entry and FID 84h reports actual WPS.

FID: Feature Identifier

Check support/entry permission, Set and Get; entering protection commits associated volatile cached data/metadata.

State and write prohibition agree while reads remain subject to normal conditions.

3. Conditions that shape the comparison

Disallowed entry or changing locked modes uses Feature Not Changeable; until-cycle mode is prohibited in multi-domain systems.

WPC is entry permission, not state; clearing it does not remove existing protection.

Sources: Base 2.4 §5.2.30.1.38, 8.1.18 · Base 2.4 §5.2.24–5.2.25, 8.1.17–8.1.17.2 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §5.2.13.1.14.2.6 · 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

Q172 How does write protection persist across reset and power?

Follow the explanation

FID 84h is non-saveable but has explicit persistent state; generic saved-feature assumptions do not apply.

FID: Feature Identifier

1. Identify the trigger and affected objects

Persistence follows the namespace, not one access controller.

Read current WPS and record the actual reset/power event.

2. State changes and recovery

WPS1/3 persist across reset/power; WPS2 survives non-power CLR and clears to 0 on power cycle.

Set baseline, perform the selected event and verify state/behavior; clearingCC.EN is not power cycling.

WPS2 remaining protected after controller reset is correct; actual power cycling releases it.

3. Verify retention and recovery

No default value exists; Get Default returns Invalid Field, not a fabricated restoration value.

Compare WPS and actual write/format restrictions.

First establish whether a real power cycle occurred.

Sources: Base 2.4 §5.2.30.1.38, 8.1.18 · Base 2.4 §4.4 · Base 2.4 §5.2.24–5.2.25, 8.1.17–8.1.17.2 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §5.2.13.1.14.2.6 · 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

Q173 How does protection affect format, sanitize and namespace management?

Follow the explanation

Protection covers operations modifying the namespace, including broad commands not naming it directly.

1. Mechanism and scope

All attached paths enforce protection, including covering Format/subsystem-sanitize scopes.

Reads/Compare/Verify generally remain allowed; Flush succeeds without effect after cache commitment. Attachment is allowed, while modifying deletion/format/sanitize is restricted.

2. Understand it through actions and results

Check WPS, scope and Figure 737 permitted actions.

Compute full impact before checking each namespace’s protection and command exceptions.

Allowed queries succeed while prohibited changes are rejected across paths.

3. Avoid a misleading conclusion

Prohibited modifications use Namespace is Write Protected; ignoring SMART critical warnings for sanitize does not bypass namespace protection.

Cross-check direct writes and broader operations against the same protection scope.

Sources: Base 2.4 §5.2.30.1.38, 8.1.18 · Base 2.4 §5.1.1, 5.2.11 · Base 2.4 §5.2.26–5.2.27 · Base 2.4 §5.2.24–5.2.25, 8.1.17–8.1.17.2 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §5.2.13.1.14.2.6 · 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

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 · Is an asynchronous event generated?

Create/delete affect allocated inventory; attach/detach affect controller active lists. Apply per-controller support/AEC. The Admin Delete recipient does not report its own deletion notice; other eligible controllers do.

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

Identify lists establish current allocation/attachment; changed lists 04h/1Ch identify changes rather than complete state. Errors use More and applicable Error Information fields.

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

Supported Change Namespace 06h records defined management changes; do not treat attachment as creation/deletion. Write protection follows supported Set Feature-event rules.

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.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.1.1
Printed pages 139–142 · PDF 165–168 · Figure 92–93
Base 2.4 · §4.2.3
Printed pages 145–155 · PDF 171–181 · Figure 101–105
Base 2.4 · §4.4
Printed pages 166–169 · PDF 192–195 · Figure 126–127
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.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.6
Printed pages 258–259 · PDF 284–285 · Figure 247
Base 2.4 · §5.2.14.2.1
Printed pages 340–387 · PDF 366–413 · Figure 338–341
Base 2.4 · §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2
Printed pages 387–399, 402–404 · PDF 413–425, 428–430 · Figure 342–355, 360–362
Base 2.4 · §5.2.24–5.2.25, 8.1.17–8.1.17.2
Printed pages 444–448, 660–663 · PDF 470–474, 686–689 · Figure 442–450
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.38, 8.1.18
Printed pages 512, 664–666 · PDF 538, 690–692 · Figure 541, 735–737
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.5.8, 4.1.6, 5.8
Printed pages 108, 110–113, 162–163 · PDF 108, 110–113, 162–163 · Figure 132–134

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: Namespace management, attachment and protection

Check existence, access and writability separately

Questions in this volume

Q157 How are namespace management and attachment supported?

1. Select the target and information

2. Query sequence and interpretation

3. Handle missing or inconsistent evidence

Q158 How are size, capacity, format and thin provisioning selected?

1. Establish the source and scope

2. Fields, units and worked interpretation

3. Conditions that change the interpretation

Q159 How are namespace-creation resource and parameter errors reported?

1. Distinguish the failure conditions

2. Establish the cause from evidence

3. Outcome and follow-up checks

Q160 How does creation change the allocated namespace list?

1. Prepare the operation

2. Sequence and completion conditions

3. Handle unmet conditions

Q161 How are controllers selected for attachment changes?

1. Prepare the operation

2. Sequence and completion conditions

3. Handle unmet conditions

Q162 How are active and controller lists cross-checked?

1. Prepare the operation

2. Sequence and completion conditions

3. Handle unmet conditions

Q163 How are attachment relationship errors reported?

1. Distinguish the failure conditions

2. Establish the cause from evidence

3. Outcome and follow-up checks

Q164 What happens to outstanding commands during detach?

1. Mechanism and scope

2. Understand it through actions and results

3. Avoid a misleading conclusion

Q165 How are commands handled after namespace detach?

1. Distinguish the failure conditions

2. Establish the cause from evidence

3. Outcome and follow-up checks

Q166 How are nonexistent or attached namespace deletions handled?

1. Distinguish the failure conditions

2. Establish the cause from evidence

3. Outcome and follow-up checks

Q167 Which events and logs follow namespace changes?

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

Q168 How does changed-namespace overflow work?

1. Establish the source and scope

2. Fields, units and worked interpretation

3. Conditions that change the interpretation

Q169 Do namespace configuration and attachment survive resets?

1. Identify the trigger and affected objects

2. State changes and recovery

3. Checks across reset or power loss

4. Verify retention and recovery

Q170 How do private and shared namespaces differ?

1. What differs

2. How to choose and verify

3. Conditions that shape the comparison

Q171 How do write-protection modes and entry controls differ?

1. What differs

2. How to choose and verify

3. Conditions that shape the comparison

Q172 How does write protection persist across reset and power?

1. Identify the trigger and affected objects

2. State changes and recovery

3. Verify retention and recovery

Q173 How does protection affect format, sanitize and namespace management?

1. Mechanism and scope

2. Understand it through actions and results

3. Avoid a misleading conclusion

Shared rules linked from the answers

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

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

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

Source locations and existing figure guides

When you need a field guide

Jia-Chang