NVMe scenarios and source figures: lookup routes, field reasoning, worked answers and precise specification locations.
read more
NVMe Figures and Scenarios 04 · I/O Commands and Data Integrity
NVM Express Base 2.4NVM Command Set 1.3NVMe over PCIe Transport 1.4
LOOKUP · FIELD INTERPRETATION · SOURCE LOCATIONS
NVMe Figures and Scenarios 04 · I/O Commands and Data Integrity
Follow command addresses and counts into metadata, protection information and atomicity. Equal field widths do not imply equal counting rules; command success alone does not establish every persistence or atomicity guarantee.
Follow a worked scenario through the specification
The returned data below are hypothetical. Start with the need and assumptions, follow the reading route to the relevant fields, then work through the interpretation. Explanations are visible; detailed sources can be expanded.
EXERCISE 01Is an eight-block Write also atomic across power failure?
A colleague sees AWUN=7 and claims that an eight-block Write cannot be partially updated by power failure. What is missing?
Hypothetical observations and assumptions
- AWUN=7, AWUPF=1; NSFEAT.NSABP=0 and MAM=0; current Write Atomicity Normal has DN=0.
- LBA data size is 4096 bytes; this is one ordinary Write with NLB=7.
Which figures connect this scenario?
This is a specification reading route. The scenario separately explains action order and wait conditions.
- Locate atomicity parameters
Distinguish normal and power-failure parameters in the Single Atomicity Mode table and determine which scope supplies the values.
NVM Command Set 1.3 · Figure 4 NVM Command Set 1.3 · Figure 123 - Determine the Write block count
Read Write NLB. Here NLB=7 requests eight blocks, which are compared with the established atomic units.
NVM Command Set 1.3 · Figure 71 - Retain event-specific conditions
Return to the atomicity parameters to explain whole-write guarantees separately for normal operation and power failure.
NVM Command Set 1.3 · Figure 4
Follow the field interpretation
Lookup sequence: Identify CNS=01h for the NVM-defined AWUN/AWUPF fields; CNS=00h for namespace NSFEAT; Get Features FID=0Ah, SEL=0 to confirm normal atomicity is not disabled.
Step 1AWUN and AWUPF encode block counts minus one. Seven provides an eight-block normal-operation guarantee; one provides a two-block power-failure/error guarantee. NLB=7 requests eight blocks, or 32768 bytes.
Step 2Under these assumptions the Write fits the normal atomic limit but exceeds the power-failure limit. Exceeding a guarantee does not mean a torn write must occur; it means AWUPF cannot guarantee the whole eight-block update.
Step 3If the application needs an indivisible 32 KiB update across power loss, it needs an appropriate supported configuration or higher-level protection. FUA=1 adds a persistence requirement before completion; it does not expand AWUPF from two blocks to eight.
Detailed source locations
- NVM Command Set 1.3 · §4.1.5.2 · Printed pages 94–96 · PDF 94–96
- NVM Command Set 1.3 · §4.1.5.1 · Figure 123 · Identify – Identify Namespace Data Structure, NVM Command Set · Printed pages 85–86, 88 · PDF 85–86, 88
- NVM Command Set 1.3 · §2.1.4 · Printed pages 15–18 · PDF 15–18
- NVM Command Set 1.3 · §4.1.3.4 · Printed pages 67 · PDF 67
- NVM Command Set 1.3 · §3.3.6 · Figure 71 · Write – Command Dword 12 · Printed pages 54 · PDF 54
Continue with the other scenarios
EXERCISE 02Why does NAWUPF=0 not necessarily mean one block?
A decoder adds one to every atomic-unit field. Which result does it get wrong here?
Hypothetical observations and assumptions
- Controller: AWUN=7, AWUPF=3. Namespace: NSABP=1, NAWUN=15, NAWUPF=0, NABSN=0, NABSPF=0, MAM=0.
- Normal atomicity is enabled; LBA data size=4096 bytes.
Follow the field interpretation
Lookup sequence: Pair Identify CNS=01h with CNS=00h to obtain the controller baseline and namespace-specific values.
Step 1Check NSABP before interpreting namespace atomic fields. NAWUN=15 is nonzero, providing 16 blocks, or 64 KiB, for normal operation rather than only the controller’s eight-block baseline.
Step 2NAWUPF=0 has a special meaning here: use controller AWUPF rather than adding one to zero. AWUPF=3 provides four blocks, or 16 KiB, for power-failure atomicity.
Step 3NABSN=NABSPF=0 specifies no corresponding atomic boundaries. These zeros, NAWUPF’s fallback zero and controller AWUPF=0 meaning one block have different semantics. A decoder needs field-specific rules.
Detailed source locations
- NVM Command Set 1.3 · §4.1.5.2 · Printed pages 94–96 · PDF 94–96
- NVM Command Set 1.3 · §4.1.5.1 · Figure 123 · Identify – Identify Namespace Data Structure, NVM Command Set · Printed pages 85–86, 88–89 · PDF 85–86, 88–89
- NVM Command Set 1.3 · §2.1.4 · Printed pages 16–19 · PDF 16–19
EXERCISE 03Does a size-compliant Write remain atomic across a boundary?
Two Writes each contain four blocks. Why can their starting LBAs change the namespace atomicity guarantee?
Hypothetical observations and assumptions
- AWUN=0, AWUPF=0; NSABP=1, NAWUN=7, NAWUPF=7; NABSN=7, NABSPF=7, NABO=0; DN=0.
- First consider MAM=0. Write A: SLBA=8, NLB=3. Write B: SLBA=6, NLB=3.
Follow the field interpretation
Lookup sequence: Identify CNS=00h for units, boundaries, offset and NSFEAT.MAM; convert commands into actual LBA intervals before comparing.
- LBA
- Logical Block Address
Step 1A nonzero encoded boundary size of seven represents eight blocks. With NABO=0, boundaries occur at 0, 8, 16 and so on. A covers LBAs 8–11 within one interval; B covers 6–9 and crosses eight. Equal lengths do not make their positions equivalent.
Step 2MAM=0 selects Single Atomicity Mode. A satisfies the namespace whole-Write conditions here; B crosses a boundary and cannot claim the same four-block guarantee. Boundary and unit-size checks belong together.
Step 3With a valid MAM=1 configuration, B is divided into atomic LBA subranges 6–7 and 8–9. Each subrange receives its own guarantee; the two combined are still not one indivisible update.
- LBA
- Logical Block Address
| Command | Actual LBA range | Boundary at LBA 8 |
|---|---|---|
| A | 8–11 | 8 9 10 11: one interval |
| B | 6–9 | 6 7 | 8 9: crosses the boundary |
Detailed source locations
- NVM Command Set 1.3 · §2.1.4.4 · Printed pages 19 · PDF 19
- NVM Command Set 1.3 · §2.1.4.5 · Printed pages 19–20 · PDF 19–20
- NVM Command Set 1.3 · §4.1.5.1 · Figure 123 · Identify – Identify Namespace Data Structure, NVM Command Set · Printed pages 85, 88–89 · PDF 85, 88–89
EXERCISE 04Does a successful Write already establish persistence?
With capability data, feature values and a command trace, how can you assess persistence of a successful Write?
Hypothetical observations and assumptions
- A volatile write cache is confirmed present and enabled for this namespace; Get Features FID=06h reports WCE=1.
- A: ordinary Write, FUA=0, successful, with no later Flush. B: Write, FUA=1, successful.
Follow the field interpretation
Lookup sequence: Identify CNS=01h for VWC, CNS=08h for VWCNP and the applicable FDP configuration → Get Features FID=06h, SEL=0 → command FUA and subsequent Flush trace.
- FDP
- Flexible Data Placement
Step 1A may already be on nonvolatile media or may still depend on volatile cache. Its successful completion alone does not distinguish those states, so neither definite persistence nor definite cache-only residency follows.
Step 2B’s FUA=1 requires this command’s data and metadata to reach nonvolatile media before completion. Persistence concerns retention after completion; atomicity concerns whether an update can be partial. They are separate questions.
Step 3Another route is to wait for A to complete, then submit a covering Flush and verify its successful completion. Flush covers completed commands for its target namespace before Flush submission. Concurrent submission would lack that ordering condition.
Detailed source locations
- Base 2.4 · §5.2.14.2.1 · Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent · Printed pages 374 · PDF 400
- Base 2.4 · §5.2.14.2.8 · Figure 346 · Identify – I/O Command Set Independent Identify Namespace Data Structure · Printed pages 391–394 · PDF 417–420
- Base 2.4 · §5.2.30.1.4 · Figure 471 · Volatile Write Cache – Command Dword 11 · Printed pages 464–465 · PDF 490–491
- Base 2.4 · §7.2 · Printed pages 567 · PDF 593
- NVM Command Set 1.3 · §3.3.6 · Figure 71 · Write – Command Dword 12 · Printed pages 54 · PDF 54
EXERCISE 05Why order data and index Writes if both use FUA?
An application places a data Write and then its index Write in the same SQ. Both use FUA=1. Is the index prevented from becoming persistent first?
- SQ
- Submission Queue
Hypothetical observations and assumptions
- Data and index use different LBA ranges and are not a fused operation.
- Both are submitted without waiting for the first completion. The goal is to avoid a new index pointing at data not yet persisted after power loss.
Follow the field interpretation
Lookup sequence: Inspect FUA in the SQEs and the submission/completion timeline; apply NVM command-ordering and Write FUA rules.
Step 1SQ position does not enforce this data dependency. FUA=1 imposes persistence before each command completes; it does not add an ordering guarantee between separate commands.
- SQ
- Submission Queue
Step 2A suitable illustrative sequence is: submit data Write with FUA=1 → verify successful completion → submit index Write with FUA=1 → verify successful completion. The first completion establishes data persistence before index submission.
Step 3This resolves the stated dependency, not a multi-command transaction. Requiring data and index to revert together or update together needs a fuller transaction or recovery design.
| Order | Host observation/action |
|---|---|
| 1 | Submit data Write, FUA=1 |
| 2 | Wait for and verify data Write success |
| 3 | Only then submit index Write, FUA=1 |
| 4 | Wait for and verify index Write success |
Detailed source locations
- NVM Command Set 1.3 · §2.1.2 · Printed pages 14 · PDF 14
- NVM Command Set 1.3 · §3.3.6 · Figure 71 · Write – Command Dword 12 · Printed pages 54 · PDF 54
EXERCISE 06How does PRACT=1 affect metadata larger than PI?
- PI
- Protection Information
A port subtracts eight metadata bytes per LBA whenever PRACT=1. Is that correct here?
Hypothetical observations and assumptions
- 16-bit Guard with PI enabled; LBA data=4096 bytes, MS=16, separate metadata buffer.
- Write has PRACT=1 and NLB=3; other protection settings are valid.
Follow the field interpretation
Lookup sequence: Identify CNS=00h for LBAF, DPS and metadata settings, plus CNS=05h with CSI=00h for ELBAF where needed → apply Write 16-bit Guard processing rules.
- CSI
- Command Set Identifier
Step 1NLB=3 requests four blocks. The data buffer is 4×4096=16384 bytes. In this metadata-greater-than-eight branch, the host still transfers 4×16=64 metadata bytes, not 32.
Step 2PRACT controls PI generation and processing, not a universal subtract-eight buffer rule. Exactly eight metadata bytes uses a different branch in the processing table; it cannot be applied to MS=16.
- PI
- Protection Information
Step 3Beyond length, align separate versus extended placement, PI type and Guard format. Only with matching conditions is a byte-level comparison between transfers meaningful.
Detailed source locations
- NVM Command Set 1.3 · §4.1.5.1 · Figure 125 · LBA Format Data Structure, NVM Command Set Specific · Printed pages 94 · PDF 94
- NVM Command Set 1.3 · §4.1.5.3 · Figure 128 · Extended LBA Format Data Structure, NVM Command Set Specific · Printed pages 101–102 · PDF 101–102
- NVM Command Set 1.3 · §5.2.3 · Figure 154 · Metadata – Transferred as Separate Buffer · Printed pages 130 · PDF 130
- NVM Command Set 1.3 · §5.3.2.1 · Figure 174 · Write Command 16b Guard Protection Information Processing · Printed pages 143 · PDF 143
EXERCISE 07Is FFh after deallocation a failure?
A validator requires every deallocated LBA to return zero. Could it reject permitted behavior?
Hypothetical observations and assumptions
- The range is confirmed deallocated; DLFEAT.DRB=010b; Get Features FID=05h reports DULBE=0.
- PI is disabled in this example; Read succeeds and all data bytes are FFh.
Follow the field interpretation
Lookup sequence: Identify CNS=00h for DLFEAT and relevant capabilities; Get Features FID=05h, SEL=0 for the target NSID to read DULBE; then assess Read results.
- NSID
- Namespace Identifier
Step 1DRB=010b describes FFh contents for deallocated reads, so this example agrees with the reported behavior. Successful Read does not inherently require zero; the validator should derive its expectation from DRB.
Step 2If DULBE is supported and enabled, deallocated/unwritten reads can instead take the error-reporting path. Preserve the feature state when comparing devices rather than only comparing returned bytes.
Step 3This tests logical-interface deallocation behavior, not secure erasure of every physical-media copy. Sanitize claims require evidence about that operation’s support, target and completion state.
Detailed source locations
- NVM Command Set 1.3 · §4.1.5.1 · Figure 123 · Identify – Identify Namespace Data Structure, NVM Command Set · Printed pages 88 · PDF 88
- NVM Command Set 1.3 · §3.3.3.2.1 · Printed pages 48 · PDF 48
- NVM Command Set 1.3 · §4.1.3.3 · Printed pages 66 · PDF 66
01Atomicity Parameters for Single Atomicity Mode
NVM Command Set 1.3 · Figure 4 · Atomicity Parameters for Single Atomicity Mode
§2.1.4 · Printed pages 15–16 · PDF 15–16
01.1 · UseUse this table to organize controller baselines, namespace-specific values and boundaries when assessing whole-write atomicity. It explicitly concerns Single Atomicity Mode.
01.2 · Fields and relationshipsAWUN/AWUPF distinguish normal and power-failure conditions; ACWU applies to fused Compare and Write. The NA-prefixed fields are namespace values. NABSN/NABSPF and NABO define boundaries. Inequalities constrain supported parameters; decode each field’s representation separately.
01.3 · Interpretation and exampleEven a write within NAWUN can lose the namespace-level whole-write guarantee if it crosses an atomic boundary in Single Atomicity Mode. Check mode, unit size, starting address and extent rather than NLB alone.
Back to this volume’s figure index02Atomic Boundaries Example
NVM Command Set 1.3 · Figure 8 · Atomic Boundaries Example
§2.1.4.4 · Printed pages 19 · PDF 19
02.1 · UseThe diagram divides LBA space into atomic-boundary intervals. Colors distinguish intervals, not namespaces or media.
02.2 · Fields and relationshipsNABO positions the first boundary; decoded boundary size spaces subsequent ones. SLBA and block count locate the write. NABSN/NABSPF cover different conditions, with special zero and minus-one encodings in the original fields.
- SLBA
- Starting Logical Block Address
02.3 · Interpretation and exampleFor a decoded boundary size of 8 blocks and offset 0, LBAs 4–7 stay within one interval while 6–9 cross boundary 8. Both contain four blocks, but size alone cannot establish the Single Atomicity whole-write guarantee for the latter.
Back to this volume’s figure index03Opcodes for NVM Commands
NVM Command Set 1.3 · Figure 22 · Opcodes for NVM Commands
§3.3 · Printed pages 27 · PDF 27
03.1 · UseMap opcodes to NVM I/O commands here. The same opcode can have a different meaning on Admin and I/O queues.
03.2 · Fields and relationshipsRows provide opcode, command and definition location, including Flush 00h, Write 01h, Read 02h, Compare 05h, Write Zeroes 08h, Dataset Management 09h, Verify 0Ch and Copy 19h. Check capabilities for support.
03.3 · Interpretation and exampleOPC=02h on an NVM I/O SQ means Read; on Admin SQ this table does not apply. Preserve queue type, CSI and opcode together to avoid mistaking log retrieval for media reads.
- CSI
- Command Set Identifier
04Read – Command Dword 10 and Command Dword 11
NVM Command Set 1.3 · Figure 53 · Read – Command Dword 10 and Command Dword 11
§3.3.4 · Printed pages 49 · PDF 49
04.1 · UseCombine CDW10/11 into the full SLBA when checking a Read address. It addresses logical blocks within the namespace, not host memory.
- SLBA
- Starting Logical Block Address
04.2 · Fields and relationshipsSLBA is 64 bits: low 32 in CDW10 and high 32 in CDW11. Its byte position depends on the current LBA size; CDW12.NLB supplies the length separately.
04.3 · Interpretation and exampleCDW11=1 and CDW10=0 means SLBA=4294967296, not LBA 0. The inclusive final LBA is SLBA+NLB because raw NLB encodes block count minus one.
Back to this volume’s figure index05Read – Command Dword 12
NVM Command Set 1.3 · Figure 54 · Read – Command Dword 12
§3.3.4 · Printed pages 49 · PDF 49
05.1 · UseUse CDW12 when Read length, recovery or protection behavior differs from expectation. Its controls are separate mechanisms, not one “strict read” switch.
05.2 · Fields and relationshipsNLB bits 15:0 encodes blocks minus one; CETYPE bits 19:16 selects extensions; STC bit 24 checks Storage Tags; PRINFO bits 29:26 controls PI action/checks. FUA bit 30 commits relevant data/metadata to nonvolatile media and reads it from there. LR bit 31 requests limited retries.
05.3 · Interpretation and exampleNLB=7 with 4096-byte blocks transfers 32768 data bytes. FUA does not order other commands, and LR does not guarantee a fixed completion deadline.
Back to this volume’s figure index06Write – Command Dword 10 and Command Dword 11
NVM Command Set 1.3 · Figure 70 · Write – Command Dword 10 and Command Dword 11
§3.3.6 · Printed pages 54 · PDF 54
06.1 · UseSeparate the destination LBA from the host source buffer when investigating misplaced writes. This figure defines Write SLBA, not PRP or SGL addresses.
- PRP
- Physical Region Page, a data-page pointer
- SGL
- Scatter Gather List
06.2 · Fields and relationshipsCDW10/11 combines low/high 32-bit halves into a 64-bit SLBA. Units are blocks of the selected namespace format, not universally 512-byte sectors.
06.3 · Interpretation and exampleSLBA=8 corresponds to byte 4096 with 512-byte blocks and byte 32768 with 4 KiB blocks. Confirm the format before comparing application byte-offset calculations.
Back to this volume’s figure index07Write – Command Dword 12
NVM Command Set 1.3 · Figure 71 · Write – Command Dword 12
§3.3.6 · Printed pages 54 · PDF 54
07.1 · UseInspect FUA and PI controls when determining what Write completion guarantees, retaining namespace format and cache context. Completion does not automatically persist every other write.
07.2 · Fields and relationshipsNLB bits 15:0 is blocks minus one; CETYPE bits 19:16 and DTYPE bits 23:20 select extensions and directives. STC bit 24/PRINFO bits 29:26 control protection. FUA bit 30 requires this command’s data/metadata on nonvolatile media before completion; LR bit 31 controls recovery effort.
07.3 · Interpretation and exampleFUA=1 strengthens this Write’s completion condition without implicitly ordering another Write. For FDP or Streams, decode CDW13 using DTYPE and CETYPE rather than assigning a fixed meaning to the same identifier bits.
- FDP
- Flexible Data Placement
08Copy – Copy Descriptor Formats
NVM Command Set 1.3 · Figure 39 · Copy – Copy Descriptor Formats
§3.3.2 · Printed pages 32 · PDF 32
08.1 · UseSelect the Copy descriptor format before decoding its source list. It determines presence of source NSID and PI layout; a wrong format shifts the interpretation of subsequent bytes.
- NSID
- Namespace Identifier
08.2 · Fields and relationshipsFormats 0/1 omit SNSID and use the destination namespace as source; 2/3 include SNSID and permit a different source.0/2 use 8-byte 16-bit-Guard PI; 1/3 use 16-byte 32/64-bit-Guard PI. Format 4 references SLM, whose full definition is outside the three supplied sources.
08.3 · Interpretation and exampleFor DF=2, do not use a format 0 decoder that assumes SNSID is absent. Cross-namespace support, format compatibility and range limits still require Copy capability and command checks.
Back to this volume’s figure index09Dataset Management – Range Definition
NVM Command Set 1.3 · Figure 47 · Dataset Management – Range Definition
§3.3.3 · Printed pages 45 · PDF 45
09.1 · UseThis table maps Dataset Management range indices to byte positions. An index counts entries; an offset counts bytes from the buffer start.
09.2 · Fields and relationshipsEach entry is 16 bytes: CATTR at relative 3:0, LLB bytes 7:4 and SLBA bytes 15:8. Entry i starts at 16×i. LLB directly counts blocks rather than using Read/Write’s plus-one NLB encoding. NR separately specifies the command’s range count.
09.3 · Interpretation and exampleThe second entry, index 1, starts at byte 16. SLBA=100 with LLB=8 describes LBAs 100–107, not nine blocks. Processing extent also depends on DMRL/DMRSL/DMSL and support-variant capabilities.
Back to this volume’s figure index10Write Zeroes – Command Dword 12
NVM Command Set 1.3 · Figure 83 · Write Zeroes – Command Dword 12
§3.3.8 · Printed pages 59–60 · PDF 59–60
10.1 · UseDistinguish range zeroing, deallocation requests and whole-namespace zeroing here. Similar names do not confer Sanitize’s security guarantees.
10.2 · Fields and relationshipsNLB bits 15:0 encodes blocks minus one. NSZ bit 23 requests whole-namespace processing in conjunction with DEAC bit 25 and support. STC bit 24 and PRCHK must be zero. FUA bit 30 specifies the nonvolatile completion condition.
10.3 · Interpretation and exampleNSZ=1 with DEAC=0 returns Invalid Field in Command. With NSZ=1, the controller ignores NLB, so NLB=0 cannot be used to infer a one-block operation. Establish scope from NSZ and capabilities first.
Back to this volume’s figure index11Metadata – Contiguous with LBA Data, Forming Extended LBA
NVM Command Set 1.3 · Figure 153 · Metadata – Contiguous with LBA Data, Forming Extended LBA
§5.2.3 · Printed pages 129 · PDF 129
11.1 · UseUse this diagram to calculate transfer length and successive block positions in extended-LBA layout. It does not place one metadata batch after the entire data batch.
11.2 · Fields and relationshipsEach block’s data is followed by its metadata, then the next block. Both use the data buffer. LBADS defines data size, MS metadata bytes, and namespace configuration selects the layout.
11.3 · Interpretation and exampleWith 4096 data bytes and 8 metadata bytes per block, the second starts at 4104 and the third at 8208. A4096-byte stride incorrectly treats metadata as the next block’s beginning.
Back to this volume’s figure index12Metadata – Transferred as Separate Buffer
NVM Command Set 1.3 · Figure 154 · Metadata – Transferred as Separate Buffer
§5.2.3 · Printed pages 130 · PDF 130
12.1 · UseThis diagram pairs two separate buffers by LBA. Physical separation does not remove the one-to-one relationship between each block and its metadata.
12.2 · Fields and relationshipsDPTR describes data and MPTR metadata, each ordered by LBA. PRP-form metadata uses physically contiguous memory; SGL metadata follows PSDT and support requirements.
- SGL
- Scatter Gather List
12.3 · Interpretation and exampleTwo blocks of 4096+8 bytes require 8192 data bytes and 16 separate metadata bytes. Merely pointing MPTR after byte 8192 of a data allocation does not create valid metadata; it must describe the prepared metadata storage.
Back to this volume’s figure index1316b Guard Protection Information Format when STS field is cleared to 0h
NVM Command Set 1.3 · Figure 155 · 16b Guard Protection Information Format when STS field is cleared to 0h
§5.3.1.1 · Printed pages 131 · PDF 131
13.1 · UseThis layout applies to 16-bit Guard PI with STS=0 and is useful for checking offsets and byte order. It is not a universal PI layout.
13.2 · Fields and relationshipsGuard occupies bytes 0–1, Application Tag 2–3 and Reference Tag 4–7. MSB at the lower byte position means these multibyte PI fields use most-significant byte first, unlike ordinary little-endian NVMe fields.
13.3 · Interpretation and exampleReference Tag 00000001h is stored 00 00 00 01 here, not 01 00 00 00. For nonzero STS, use the Storage/Reference split instead of assuming all 32 bits remain Reference Tag.
Back to this volume’s figure index1432b Guard Protection Information Format
NVM Command Set 1.3 · Figure 157 · 32b Guard Protection Information Format
§5.3.1.2 · Printed pages 133 · PDF 133
14.1 · UseUse this figure to distinguish 32-bit and 64-bit Guard layouts even though both occupy 16 PI bytes. Changing Guard width also moves later fields.
14.2 · Fields and relationshipsGuard is bytes 0–3, Application Tag 4–5 and the 80-bit Storage/Reference space 6–15. ELBAF.STS determines the split of that final space.
14.3 · Interpretation and exampleWith STS=16, its high 16 bits are Storage Tag and the remaining 64 bits Reference Tag. Applying the 64-bit Guard layout would misplace even the Application Tag.
Back to this volume’s figure index1564b Guard Protection Information Format
NVM Command Set 1.3 · Figure 159 · 64b Guard Protection Information Format
§5.3.1.3 · Printed pages 134 · PDF 134
15.1 · UseDecode 64-bit Guard PI with this layout rather than assuming every field becomes 64 bits. The entire PI remains 16 bytes.
15.2 · Fields and relationshipsGuard occupies bytes 0–7, Application Tag 8–9 and the 48-bit Storage/Reference space 10–15. Follow the MSB/LSB byte ordering and use STS for the tag split.
15.3 · Interpretation and exampleSTS=0 leaves all 48 bits for Reference Tag; STS=48 uses all of them for Storage Tag with no Reference Tag. Absence of a field is not the same as a field whose value is zero.
Back to this volume’s figure index16Write Command 16b Guard Protection Information Processing
NVM Command Set 1.3 · Figure 174 · Write Command 16b Guard Protection Information Processing
§5.3.2.1 · Printed pages 143 · PDF 143
16.1 · UseThese four 16-bit-Guard scenarios compare host buffers with media format, particularly useful for transfer-length mismatches after enabling PI.
16.2 · Fields and relationshipsWith PRACT=0 the host transfers metadata including PI. With PRACT=1 and exactly 8 metadata bytes, those bytes are not transferred by the host and the controller generates PI. When metadata exceeds 8 bytes, its host-side size remains unchanged; do not always subtract eight.
16.3 · Interpretation and exampleFor 4096 data bytes, 8 metadata bytes and PRACT=1, the host supplies data only. With 16 metadata bytes, retain the 16-byte metadata transfer layout. PRCHK controls checks; PRACT alone does not disable every check.
Back to this volume’s figure index17Read 16b Guard Command Protection Information Processing
NVM Command Set 1.3 · Figure 175 · Read 16b Guard Command Protection Information Processing
§5.3.2.2 · Printed pages 145 · PDF 145
17.1 · UseFollow NVM→controller→host in this Read diagram. It complements the Write flow and helps verify whether returned metadata was omitted from or double-counted in buffer sizing.
17.2 · Fields and relationshipsPRACT=0 returns full metadata. PRACT=1 with exactly 8 metadata bytes removes PI from the host transfer. Metadata larger than 8 bytes retains its original size; controller PI processing does not imply that the host receives no metadata.
17.3 · Interpretation and exampleFor 16 metadata bytes, allocating only data capacity may be insufficient even with PRACT=1. Determine the transfer form here, then use namespace metadata placement to configure DPTR/MPTR.
Back to this volume’s figure index
Comments