NVMe Self-Study Bank: NVM sets, endurance groups and capacity
read more
NVMe Self-Study Bank: NVM sets, endurance groups and capacity
NVMe · Q1–328
NVM Express Base 2.4NVM Command Set 1.3NVMe over PCIe Transport 1.4
Q256–Q267
NVM sets, endurance groups and capacity
Establish ownership before interpreting layer-specific capacity and group-scoped health.
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
Capacity has multiple accounting layers
Namespace blocks, group bytes and adjusted physical consumption differ.
| Layer | Observation | Common mistake |
|---|---|---|
| Namespace | Logical size/capacity and format | Treating blocks as bytes |
| Set/group | Total/unallocated capacity | Double-counting resource pools |
| Physical allocation | Adjustment and granularity | Equating logical size and physical cost |
| Health | Group log/warnings | Using SMART counter units |
Worked interpretation: CAF200 can make 5 GiB consume 10 GiB before granularity effects; it does not double LBA size.
- LBA
- Logical Block Address
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17
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
- Q256 · How are NVM sets, endurance groups and namespaces related?
- Q257 · How are sets and groups discovered through Identify?
- Q258 · How is a namespace created in a selected set or group?
- Q259 · What happens when a set or group identifier does not exist?
- Q260 · What does the Endurance Group Information Log report?
- Q261 · How are group health warnings and events updated?
- Q262 · How are total and unallocated capacities determined?
- Q263 · How do namespace creation and deletion affect free capacity?
- Q264 · How does Capacity Management allocate and release groups and sets?
- Q265 · What happens when capacity or identifiers are exhausted?
- Q266 · Which views change after capacity reconfiguration?
- Q267 · How does storage configuration persist across reset and power cycle?
Q256 How are NVM sets, endurance groups and namespaces related?
Follow the explanation
They organize capacity, endurance and logical access rather than rename one object.
1. What differs
With set support, a formatted namespace resides in one set, each set in one group and each group in one domain.
Set lists, group logs and namespace Identify provide distinct capacity, health and membership views.
2. How to choose and verify
Read support and lists, then namespace membership identifiers.
Draw supported layers and actual IDs; absence of set support does not create a fictional Set 0 layer.
Example EG1 contains Set 2/3 and their namespaces, with endurance managed across those sets.
3. Conditions that shape the comparison
Set support requires groups; group support does not require sets.
Cross-check membership through all supported layers.
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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)
Q257 How are sets and groups discovered through Identify?
Follow the explanation
Capability, inventory and maximum identifier answer different questions.
1. Select the target and information
Discovery reflects information accessible through the queried controller.
Read support/maxima and the respective inventories.
Set attributes include capacities/membership; detailed group data comes from LID 09h.
- LID
- Log Page Identifier
2. Query sequence and interpretation
Enumerate actual IDs before reading details; do not assume every possible ID exists.
Discover inventory and distinguish absent allocation from unsupported capability.
3. Handle missing or inconsistent evidence
Required zero output for unsupported functionality does not create valid entity 0.
Reconcile advertisement, inventories, maxima and membership.
First check confusion between maximum ID and current count.
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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)
Q258 How is a namespace created in a selected set or group?
Follow the explanation
Select a resource pool while encoding logical capacity in blocks of the chosen format.
1. Prepare the operation
Creation selects placement for a new object rather than moving an existing namespace.
Check inventory, capacity and LBA format before selecting membership.
- LBA
- Logical Block Address
Create fields combine logical size/capacity, format/protection and membership.
2. Sequence and completion conditions
Both zero delegate selection; group-only selects within it; a specified set requires its correct nonzero group.
Success returns NSID; verify allocated Identify and attach separately.
- NSID
- Namespace Identifier
3. Handle unmet conditions
Nonexistent/mismatched explicit membership is not automatic selection.
Verify returned membership and the correct allocation layer.
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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)
Q259 What happens when a set or group identifier does not exist?
Follow the explanation
Zero and nonexistent nonzero identifiers differ, with zero semantics varying by command.
1. Distinguish the failure conditions
Identify whether the operation is namespace/capacity management, logging or a feature.
For example, zero ELID auto-selects a domain for group creation but is invalid for group deletion.
Invalid capacity entity selectors and nonexistent FID 18h groups require Invalid Field.
- FID
- Feature Identifier
2. Establish the cause from evidence
Check current inventory and command-specific special values.
Start from a valid request and isolate one nonexistent identifier.
3. Outcome and follow-up checks
Valid automatic selection returns the selected ID; invalid explicit IDs must not silently target another object.
Base has ENDGID-ignore rules when groups are unsupported; distinguish absence of capability from invalid IDs under support.
First read zero semantics for that specific command.
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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)
Q260 What does the Endurance Group Information Log report?
Follow the explanation
This log provides group-scoped health/workload rather than only aggregate SMART.
1. Establish the source and scope
LID 09h selects ENDGID and describes the group’s lifetime.
- LID
- Log Page Identifier
Establish support and existence before reading the 512-byte structure.
2. Fields, units and worked interpretation
Health, host/media data volume, command/error counts and byte capacities occupy distinct field groups.
Inspect health and difference snapshots; these data counters use rounded billions of bytes, not SMART’s 512000-byte units.
MUW includes internal writes unlike DUW; account for quantization and unreported zero values.
3. Checks across reset or power loss
| Trigger | Effect on this operation or state |
|---|---|
| What survives or continues after a power cycle? | A retained group’s lifetime information persists; feature/event configuration restoration remains a separate rule. |
4. Conditions that change the interpretation
Unreported zero is not zero consumption and cannot support a meaningful amplification ratio.
Correlate group membership and aggregate warning semantics, not bytewise equality with SMART.
5. Reporting and shared objects
Group health can be shared across readers; record acknowledgments and reader timing.
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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)
Q261 How are group health warnings and events updated?
Follow the explanation
Live health, pending-group entries and host notices form separate stages.
1. When the event exists and who observes it
FID 18h is per-group, while AEC enables aggregate-log notices.
- FID
- Feature Identifier
Inspect live health, per-group event mask and AEC notice enablement.
Group warning bits 0/2/3 indicate spare/reliability/read-only; namespace write protection must not set EGRO. Bit 1 is reserved, unlike SMART temperature.
2. Notification, reading and acknowledgment
Pending groups enter 0Fh; read it, then each 09h. Successful 09h RAE0 acknowledges/removes that group’s pending entry.
Aggregate acknowledgment is not acknowledgment of every group; current warning may already have cleared.
3. Evaluate missing notifications or records
Reserved warning bits or nonexistent groups in FID 18h require Invalid Field.
The specified aggregate SMART rule applies when all groups assert the bit, not merely one group.
First check confusion between aggregate and per-group acknowledgment.
4. Reporting and shared objects
FID 18h selects group warnings for the aggregate; AEC and AER conditions govern host notice of additions.
LID 0Fh lists pending group IDs;09h reports current group health and successful RAE0 reads acknowledge that group.
Group health can be shared across readers; record acknowledgments and reader timing.
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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)
Q262 How are total and unallocated capacities determined?
Follow the explanation
Unallocated means unallocated to a particular next layer, not universally free for any operation.
1. Select the target and information
Capacity pools exist at subsystem, domain, group or set scope.
Read controller/domain capacities, group capacities and set attributes.
Physical-capacity fields use bytes; namespace sizes use formatted blocks.
2. Query sequence and interpretation
Select the operation’s capacity source under Figure 89, including granularity and adjustment factor.
Creating a set allocates from UEGCAP without requiring another decrease in subsystem UNVMCAP.
3. Handle missing or inconsistent evidence
Zero may mean unreported under field-specific rules rather than no capacity.
Compare within one layer to avoid double counting.
First identify which entity is being created.
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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)
Q263 How do namespace creation and deletion affect free capacity?
Follow the explanation
Namespace allocation consumes its containing pool, not always controller UNVMCAP.
1. Mechanism and scope
Use the supported containing layer: set, group or domain/subsystem.
Logical size/capacity and physical consumption differ because of allocation granularity.
2. Understand it through actions and results
Preserve membership, format, actual NVMCAP and pool snapshots.
After creation/deletion verify inventory and the corresponding pool.
Capacity follows allocation rules; Detach alone does not return namespace capacity.
3. Avoid a misleading conclusion
Capacity exhaustion differs from identifier/count exhaustion.
Verify allocation separately from data sanitization; deletion is not proof of purge.
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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)
Q264 How does Capacity Management allocate and release groups and sets?
Follow the explanation
Fixed selects supported layouts; Variable creates entities by requested capacity.
1. Prepare the operation
Changes can cascade to contained namespaces and all paths.
Check management/deletion support and supported fixed configurations.
OPER selects layout/create/delete/restore; ELID meaning varies and CAPU:CAPL encodes create bytes.
2. Sequence and completion conditions
Variable allocation proceeds group→set→namespace; fixed reconfiguration follows clearing/selection prerequisites.
Creation returns CELID; other operations do not universally return a valid created ID.
3. Handle unmet conditions
Deletion cascades; default restoration with remaining groups/sets requires Command Sequence Error.
Requery final lists/ownership/capacity; intermediate accesses may be indeterminate.
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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)
Q265 What happens when capacity or identifiers are exhausted?
Follow the explanation
Capacity exhaustion and identifier exhaustion are distinct limits.
1. Distinguish the failure conditions
Group creation checks relevant pool/max size; set creation checks UEGCAP.
Interpret requested bytes with adjustment and allocation granularity.
Capacity shortage returns 1/26h; identifier exhaustion returns 1/2Dh.
2. Establish the cause from evidence
Inspect capacity limits and inventory.
Isolate capacity and identifier exhaustion in separate scenarios.
3. Outcome and follow-up checks
Adequate resources create an entity and return CELID; failure must not fabricate one.
Prose specifies largest creatable capacity in CSINFO, while Figure 165 describes required capacity. Preserve this conflict rather than using one interpretation as an unconditional conformance oracle.
First identify the exhausted resource, then the CSINFO source ambiguity.
4. Evidence supplied by the log
Insufficient-capacity creation requires the stated CSINFO detail when Error Log is supported; preserve the prose/Figure 165 semantic conflict.
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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)
Q266 Which views change after capacity reconfiguration?
Follow the explanation
Validate coherent views, not just successful CQE.
- CQE
- Completion Queue Entry
1. Prepare the operation
Inspect affected group/set/namespace/domain/media relationships.
Preserve inventory, capacity and ownership snapshots.
Group creation changes parent capacity; set creation changes set inventory/UEGCAP but not UNVMCAP; deletion follows its cascade.
2. Sequence and completion conditions
Read after completion and account for concurrent management.
Deleting a set removes its namespaces, clears applicable media ownership and returns group capacity.
3. Handle unmet conditions
Ordered intermediate updates are not universally atomic byte-for-byte to all readers.
Verify the full chain of inventory, child removal, accounting and rediscovery notices.
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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)
Q267 How does storage configuration persist across reset and power cycle?
Follow the explanation
Storage organization is distinct from transient I/O queues; reset is not configuration deletion.
1. Identify the trigger and affected objects
Compare completed entity membership and capacity accounting.
Snapshot configuration, identity, capacities and outstanding management.
2. State changes and recovery
OPER5 default restoration is separate and has inventory prerequisites.
Rediscover after channel recovery; interrupted operations require outcome discovery rather than assumed rollback.
Completed configuration remains identifiable; explain differences through actual management/state changes.
3. Checks across reset or power loss
| Trigger | Effect on this operation or state |
|---|---|
| What survives or continues after Controller Reset? | Completed storage configuration is not volatile queue state and is not deleted by ordinary CLR. Requery interrupted operations rather than assume rollback. |
| What survives or continues after NVM Subsystem Reset? | Subsystem reset is distinct from restoring default capacity configuration; rediscover retained storage configuration unless a separate management action changed it. |
| What survives or continues after a power cycle? | Completed configuration persists across power cycles; requery interrupted operations because missing CQE does not prove no effect. |
- CQE
- Completion Queue Entry
4. Verify retention and recovery
Missing completion establishes uncertainty, not an unchanged configuration.
Distinguish temporary query unavailability from missing persistent configuration.
First check for separate restore/delete/reconfiguration activity.
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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
Sources: Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.3 · Base 2.4 §8.1.4 · Base 2.4 §5.2.13.1.10 · Base 2.4 §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17 · 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 · NVM Command Set 1.3 §4.1.5.8, 4.1.6, 5.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 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.2–3.2.3, 3.8
Printed pages 80–84, 125–129 · PDF 106–110, 151–155 · Figure 67–69, 86–89 - Base 2.4 · §3.2.3.1, 5.2.13.1.15, 5.2.30.1.17
Printed pages 84, 270, 478 · PDF 110, 296, 504 · Figure 261, 493 - 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.2.2
Printed pages 183–190 · PDF 209–216 · Figure 150–156 - Base 2.4 · §5.2.3
Printed pages 191–195 · PDF 217–221 · Figure 162–166 - Base 2.4 · §5.2.13.1.2
Printed pages 218–220 · PDF 244–246 · Figure 212 - Base 2.4 · §5.2.13.1.10
Printed pages 237–239 · PDF 263–265 · Figure 224–225 - 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.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 · §8.1.4
Printed pages 594–597 · PDF 620–623 - 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.
- Base 2.4 Figure 101 · Completion Queue Entry: Status Field
- Base 2.4 Figure 104 · Status Code – Command Specific Status Values
- Base 2.4 Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent
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
Comments