An NVMe technical report covering the main ideas, mechanisms, conditions, and examples.
read more
NVM Command Set 1.3: Logical blocks, I/O commands, and data protection
NVM Express Base 2.4NVM Command Set 1.3NVMe over PCIe Transport 1.4
Start with one command
00.01.For a Read or Write, first establish the namespace (logical storage space) format. Then interpret the LBA (Logical Block Address), block count, and data pointers, followed by completion status and the required persistence, atomicity, and protection conditions.
- logical block
- An addressable unit in a namespace; its data size is determined by the active format.
- namespace
- Namespace, a formatted quantity of non-volatile memory accessed by a host through a controller.
- LBA
- Logical Block Address, measured in blocks of the selected format.
00.02.Base 2.4 supplies the common submission/completion mechanism; NVM Command Set 1.3 adds block-command semantics. Follow one data operation first, then the management and advanced topics; they are not mandatory stages of every I/O.
- I/O
- Input/Output, the class of data operations performed on a namespace.
- NVM
- Non-Volatile Memory, memory that retains data without power.
Continue along this reading route
First: which Identify data describes this namespace?
00.03.Connect common namespace data, NVM-specific data, and format lists to establish data size and metadata arrangement.
- namespace
- Namespace, a formatted quantity of non-volatile memory accessed by a host through a controller.
- metadata
- Additional information stored with a logical block; it can contain protection information or serve other purposes.
- NVM
- Non-Volatile Memory, memory that retains data without power.
Next: connect the range to transfer size
00.04.Read SLBA, zero-based NLB, and data pointers, then trace data and metadata under the selected format.
- zero-based
- zero-based: numbering starts at zero, so raw=3 can mean the fourth item or four units; the field definition still decides which.
- metadata
- Additional information stored with a logical block; it can contain protection information or serve other purposes.
- SLBA
- Starting LBA; Starts the command range.
- NLB
- Number of Logical Blocks; this field in the report’s commands/status descriptors is zero-based. DSM LLB is separately one-based.
Then: which guarantees apply?
00.05.Apply normal/power-fail atomicity, ordering, and protection under their conditions; follow Copy and resource management in their own sections.
Sources: NVM Command Set 1.3 §1.1-1.6; 4.1.3.9; 4.1.4.8; 4.1.5 · NVM Command Set 1.3 §4.1.5 · NVM Command Set 1.3 §2.1.6; 5.2.3; 5.3 · NVM Command Set 1.3 §3.3.4; 3.3.6
Source: NVME-NVM-CS-1.3, Rev. 1.3, §1.1-1.6; 4.1.3.9; 4.1.4.8; 4.1.5, printed pages 9-12,73-75,79-83, PDF pages 9-12,73-75,79-83
Source: NVME-NVM-CS-1.3, Rev. 1.3, §4.1.5, printed pages 83-110, PDF pages 83-110
Source: NVME-NVM-CS-1.3, Rev. 1.3, §2.1.6; 5.2.3; 5.3, printed pages 22,129-131, PDF pages 22,129-131
Source: NVME-NVM-CS-1.3, Rev. 1.3, §3.3.4; 3.3.6, printed pages 48-51,53-56, PDF pages 48-51,53-56
01 Namespace capacity and allocation
01.01.Separate logical address space from allocated resources before considering writes and deallocation. Interpret returned data as command output and determine allocation from its rules; returned content alone does not establish allocation.
- NCAP
- Namespace Capacity, the maximum number of simultaneously allocated logical blocks.
- NSZE
- Namespace Size, the total number of addressable logical blocks.
- NUSE
- Namespace Utilization, the number of currently allocated logical blocks.
- LBA
- Logical Block Address, measured in blocks of the selected format.
01.02.NSZE ≥ NCAP ≥ NUSE: NSZE defines the addressable range, NCAP limits simultaneously allocated blocks, and NUSE counts current allocation. THINP=0 requires NCAP=NSZE. NVMCAP is measured in bytes and is not necessarily NSZE multiplied by data size.
- NVMCAP
- NVM Capacity, measured in bytes; not directly comparable to NSZE/NCAP logical-block counts.
- THINP
- Thin Provisioning, the NSFEAT bit governing whether NCAP may be below NSZE and whether the controller tracks NUSE.
- NCAP
- Namespace Capacity, the maximum number of simultaneously allocated logical blocks.
- NSZE
- Namespace Size, the total number of addressable logical blocks.
- NUSE
- Namespace Utilization, the number of currently allocated logical blocks.
Sources: NVM Command Set 1.3 §2.1.1; 4.1.5.1
Source: NVME-NVM-CS-1.3, Rev. 1.3, §2.1.1; 4.1.5.1, printed pages 13-14,85-93, PDF pages 13-14,85-93
| Capacity or operation | Range or change described | What affects the interpretation |
|---|---|---|
| NSZE | Valid LBAs run from 0 to NSZE−1 | Out-of-range differs from capacity exhaustion |
| THINP | Requires NUSE tracking when supported | Without support NUSE may remain NCAP |
| Allocation | Write, the Copy destination, and WU allocate | Read/Verify do not change deallocation state |
- THINP
- Thin Provisioning, the NSFEAT bit governing whether NCAP may be below NSZE and whether the controller tracks NUSE.
02 Metadata transfer and PI placement
02.01.Metadata need not consist entirely of PI. Mark data, non-PI metadata, and PI separately before computing host-buffer size and CRC coverage.
- Host
- The system running the operating system and issuing NVMe commands.
- CRC
- Cyclic Redundancy Check: a check value computed from data bits to detect changes.
- PI
- Protection Information: Guard and tag fields used to check data and its associated information.
- DPTR
- Command data pointer: destination for Read, source for Write, descriptors for Copy/DSM.
- MPTR
- Separate-metadata pointer; namespace format and command fields determine metadata placement.
02.02.Formatting selects one metadata transfer mechanism per namespace: contiguous extended LBAs or a separate buffer addressed by MPTR. Metadata cannot be split between the mechanisms and must be written atomically with its associated logical block.
- logical block
- An addressable unit in a namespace; its data size is determined by the active format.
- MPTR
- Separate-metadata pointer; namespace format and command fields determine metadata placement.
Sources: NVM Command Set 1.3 §2.1.6; 5.2.3; 5.3
Source: NVME-NVM-CS-1.3, Rev. 1.3, §2.1.6; 5.2.3; 5.3, printed pages 22,129-131, PDF pages 22,129-131
| Transfer arrangement or location | Host buffer arrangement | Format constraints |
|---|---|---|
| Extended LBA | DPTR addresses interleaved data+metadata | MSET/MTELBA reflect the selection |
| Separate buffer | DPTR addresses data; MPTR addresses metadata | PRP metadata is physically contiguous; SGL metadata may be scattered |
| PI location | Valid current formats put PI at the metadata end | CRC covers preceding non-PI metadata |
- DPTR
- Command data pointer: destination for Read, source for Write, descriptors for Copy/DSM.
- CRC
- Cyclic Redundancy Check: a check value computed from data bits to detect changes.
- PRP
- Physical Region Page, a pointer format describing a host-addressable data buffer in memory-page units.
- SGL
- Scatter Gather List, a descriptor-and-segment format for one or more data-buffer regions.
- PI
- Protection Information: Guard and tag fields used to check data and its associated information.
03 Read/Write data and completion
03.01.Check range, buffer, PI, and completion separately to distinguish addressing errors, format mismatches, and media failures.
03.02.Read/Write specify a contiguous range with SLBA and zero-based NLB. DPTR is a destination buffer for Read and a source buffer for Write. FUA=1 requires nonvolatile-media handling without implying ordering of other commands.
- zero-based
- zero-based: numbering starts at zero, so raw=3 can mean the fourth item or four units; the field definition still decides which.
- SLBA
- Starting LBA; Starts the command range.
- FUA
- Force Unit Access; requires nonvolatile-media semantics without automatically ordering other commands.
- NLB
- Number of Logical Blocks; this field in the report’s commands/status descriptors is zero-based. DSM LLB is separately one-based.
Sources: NVM Command Set 1.3 §3.3.4; 3.3.6
Source: NVME-NVM-CS-1.3, Rev. 1.3, §3.3.4; 3.3.6, printed pages 48-51,53-56, PDF pages 48-51,53-56
| Command field | Data or operation described | Selections affecting interpretation |
|---|---|---|
| CDW10 / CDW11 | Low/high 32 bits of SLBA | NLB=0 still requests one block |
| CDW12 | LR, FUA, PRINFO, STC, CETYPE, NLB | The DTYPE area is reserved for Read |
| CDW13 | CETYPE selects DSM or CEV interpretation | Write also carries DTYPE/DSPEC |
| MPTR | Used for separate metadata | Do not split metadata between both mechanisms |
- CETYPE
- Command Extension Type; Selects the interpretation of the command extension value CEV.
- PRINFO
- Protection Information; The command field combining PRACT and PRCHK.
- DSPEC
- Directive Specific; Its contents depend on the Directive type.
- DTYPE
- Directive Type; Selects the Directive type for the command.
- CDW
- CDW (Command Dword): a 32-bit command field. In CDW10, 10 is the field index, not a byte offset.
- CEV
- Command Extension Value; Its contents are interpreted according to CETYPE.
- DSM
- Dataset Management: host hints about use and allocation of data ranges.
- FUA
- Force Unit Access; requires nonvolatile-media semantics without automatically ordering other commands.
- STC
- Storage Tag Check, separate from three-bit PRCHK and ignored when STS=0.
- LR
- Limited Retry; selects retry behavior governed by Error Recovery policy.
04 Normal, power-fail, and multiple atomicity
04.01.Read size, starting alignment, NSABP, and MAM together. Atomicity and persistence on nonvolatile media are separate checks; FUA/Flush do not establish ordering for other commands.
- NSABP
- Namespace Atomic Boundary Parameters: indicates applicability of namespace atomic-write parameters.
- MAM
- Multiple Atomicity Mode; a crossing command is divided into independently atomic subranges.
04.02.AWUN/NAWUN and AWUPF/NAWUPF describe normal and failure-condition atomicity. Single Atomicity Mode provides no whole-command guarantee across a boundary; Multiple Atomicity Mode divides the range at boundaries into separately atomic subranges, without promising one combined outcome.
- NAWUPF
- Namespace Atomic Write Unit Power Fail; Namespace failure-condition atomic-write size, subject to applicability and zero-value rules.
- AWUPF
- Atomic Write Unit Power Fail, the zero-based atomic size for failure conditions.
- NAWUN
- Namespace Atomic Write Unit Normal; Namespace normal atomic-write size, subject to applicability and zero-value rules.
- AWUN
- Atomic Write Unit Normal, the controller’s zero-based normal atomic-write size.
Sources: NVM Command Set 1.3 §2.1.4; 4.1.3.4; 5.9
Source: NVME-NVM-CS-1.3, Rev. 1.3, §2.1.4; 4.1.3.4; 5.9, printed pages 15-21,66-67,165, PDF pages 15-21,66-67,165
| Atomicity field or mode | Range governed | What it does not establish |
|---|---|---|
| AWUN / AWUPF | Sizes use zero-based encoding | AWUPF does not exceed AWUN |
| NABO / NABSN / NABSPF | Boundaries occur at offset + k × size | Read each field and its unreported cases |
| MAM | Each atomic subrange has its own guarantee | Fused operations still use Single mode |
| FID 0Ah.DN | DN=1 releases normal-atomicity requirements | Power-fail guarantees remain |
- NABSPF
- Namespace Atomic Boundary Size Power Fail; The failure-condition atomic boundary size.
- offset
- offset: a displacement measured from a stated start. It answers “how far from the start,” unlike an index.
- AWUPF
- Atomic Write Unit Power Fail, the zero-based atomic size for failure conditions.
- NABSN
- Namespace Atomic Boundary Size Normal; The normal-operation atomic boundary size.
- AWUN
- Atomic Write Unit Normal, the controller’s zero-based normal atomic-write size.
- NABO
- Namespace Atomic Boundary Offset; determines the first boundary location.
- FID
- Feature Identifier: selects the Feature to read or configure.
- MAM
- Multiple Atomicity Mode; a crossing command is divided into independently atomic subranges.
- DN
- Disable Normal in Write Atomicity Normal; does not remove power-fail atomicity.
05 Compare content and verify integrity
05.01.Expected-content comparison, integrity verification, and ordinary Read provide different evidence. Compare excludes PI from metadata comparison and checks PI separately as requested.
05.02.Compare compares media data with a host-supplied buffer. Verify checks stored-data integrity without returning data or metadata to the host. Both require PRACT=0; Verify and Read need not report an identical error code for a detected failure.
- PRACT
- Protection Information Action; PI handling depends on command and MS.
Sources: NVM Command Set 1.3 §3.3.1; 3.3.5
Source: NVME-NVM-CS-1.3, Rev. 1.3, §3.3.1; 3.3.5, printed pages 27-30,51-53, PDF pages 27-30,51-53
| Command or size field | What is checked | Meaning of the result |
|---|---|---|
| Compare | A miscompare returns Compare Failure | PI can be checked on both host and media paths |
| Verify | No data-buffer transfer | Verified data still counts toward Data Units Read |
| VSL / NVMVFYS | The variant selects recommended size or a hard limit | Nonzero VSL uses 2^n × minimum page size |
- VSL
- Verify Size Limit; A Verify size limit, interpreted with its variant capability.
06 Copy: source descriptors, contiguous destination, partial failure
06.01.Calculate the expanded destination range before checking formats, limits, overlap, and atomicity. Copy reduces host data movement but is not an unconditional transaction.
06.02.Copy concatenates one or more source ranges in descriptor order into one contiguous destination range. Formats 0h/1h use one namespace; 2h/3h carry SNSID and require controller support and host enablement. Failure CQE DW0 is the lowest unsuccessful source index; later ranges may already have been copied.
- controller
- Controller, the entity that implements the NVMe interface, fetches commands, and reports completions.
- SNSID
- Source Namespace Identifier; Selects a Copy source namespace.
- index
- index: selects an item or format in a list. It answers “which one,” not “how far from the start.”
- CQE
- Completion Queue Entry, one completion-result structure in a CQ.
Sources: NVM Command Set 1.3 §3.3.2
Source: NVME-NVM-CS-1.3, Rev. 1.3, §3.3.2, printed pages 30-44, PDF pages 30-44
| Descriptor or behavior | Data arrangement | Limits and completion meaning |
|---|---|---|
| NR / NLB | Source count and per-range block count are zero-based | Check MSRC, MSSRL, and MCL |
| FCO | Formats 2h/3h can request fast copy only | Inspect DNR after Fast Copy Not Possible |
| Overlap | Formats 2h/3h prohibit source/destination overlap within one namespace | Formats 0h/1h need their separate overlap rules |
| NVMCSA | Revision 1.3 treats the destination as one write command | MAM, size, and boundary limits still apply |
- DNR
- Do Not Retry, a CQE-status bit indicating that retrying the same command is not expected to succeed.
- FCO
- Fast Copy Only; requests a fast-copy method for the applicable source.
- NR
- Zero-based range-count field; actual descriptor count is NR+1.
07 Combining PRACT with PRCHK/STC
07.01.First determine whether namespace PI is enabled, then choose a processing branch by command direction and metadata size. Evaluate checking bits and special disable values afterward.
07.02.PRACT controls PI transfer, insertion, stripping, or replacement. PRCHK Guard/Application/Reference bits and independent STC control checking. With PRACT=1 and MS>PI size, Read still returns all metadata; PRACT=1 does not universally mean stripping PI.
- Guard
- The PI check-value field; the selected format determines its width and calculation.
- PRCHK
- Protection Information Check bits for Guard, Application, and Reference.
- STC
- Storage Tag Check, separate from three-bit PRCHK and ignored when STS=0.
- MS
- Metadata Size; Metadata bytes per logical block.
Sources: NVM Command Set 1.3 §2.1.5; 5.3.2-5.3.3
Source: NVME-NVM-CS-1.3, Rev. 1.3, §2.1.5; 5.3.2-5.3.3, printed pages 21-22,141-152, PDF pages 21-22,141-152
| Operation or protection condition | Controller PI handling | Effect on checking or transfer size |
|---|---|---|
| Write, PRACT=1 | Insert PI when MS=PI; replace it when MS>PI | This generation branch ignores PRCHK/STC |
| Read, PRACT=1 | Perform requested checks; strip only when MS=PI | MS>PI still returns metadata including PI |
| Type 1 / Type 2 | Reference increments per block | Type1 initial value must match relevant low SLBA bits |
| Type 3 | Should not compare a computed reference | An RTCHK rejection uses Invalid Protection Information |
| Disable sentinels | Type 1/2 disable all PI checks when Application Tag=FFFFh; Type 3 additionally requires an all-ones Reference Tag, if defined | Overrides PRCHK/STC settings |
| Masks | A zero mask bit excludes comparison | Storage masking also obeys STMLA |
- Protection Information
- PI: protection fields containing a Guard and tags for checking data and its associated information.
- PRCHK
- Protection Information Check bits for Guard, Application, and Reference.
- RTCHK
- Reference Tag Check; Requests Reference Tag checking.
08 Hard/Soft modes and token-bucket examples
08.01.Interpret results using capability, configured limits, and actual demand. A configured ratio does not force a fixed throughput ratio at every instant; internal resources and workload still matter.
08.02.Hard Limit sets a ceiling; Soft Limit can use unused bandwidth/IOPS. Resource shortfalls are shared proportionally to configured limits. Appendix A illustrates multiple token buckets without requiring one identical controller implementation.
- controller
- Controller, the entity that implements the NVMe interface, fetches commands, and reports completions.
- IOPS
- Input/Output Operations Per Second; an operation rate, distinct from byte throughput.
Sources: NVM Command Set 1.3 §5.10.1-5.10.2; Appendix A
Source: NVME-NVM-CS-1.3, Rev. 1.3, §5.10.1-5.10.2; Appendix A, printed pages 166-168,176-177, PDF pages 166-168,176-177
| Mode or command | Sharing or consumption of credits | Limits on interpretation |
|---|---|---|
| Hard | Proportional sharing under demand and resource shortage | A configured ceiling is not a performance floor |
| Soft | May consume unused capacity | Multiple soft targets share it in proportion to limits |
| Write tokens | Total bytes × WRBWR; write bytes; total IOPS × WRIOPSR; one write IOPS | Check each of four buckets |
| Read tokens | Total bytes and one total IOPS | Does not consume write-only buckets |
- WRIOPSR
- Write-to-Read IOPS Ratio; The write-to-read operation-count weight.
- WRBWR
- Write-to-Read Bandwidth Ratio; The write-to-read bandwidth weight.
- IOPS
- Input/Output Operations Per Second; an operation rate, distinct from byte throughput.
Where to continue in the specification
09.01.Use the flow above to frame the problem, then open the corresponding sections for fields and full conditions. The Chinese tutorial also explains every in-scope figure with its takeaway, example, and details.
| Concept to explain | Specification sections |
|---|---|
| Logical blocks, formats, and units | NVM 1.3 §1.1-1.6; 4.1.3.9; 4.1.4.8; 4.1.5 |
| Namespace capacity and allocation | NVM 1.3 §2.1.1; 4.1.5.1 |
| Identify: multiple structures for one namespace | NVM 1.3 §4.1.5 |
| LBAF, ELBAF, and unique-attribute formats | NVM 1.3 §4.1.5.1; 4.1.5.3; 5.6 |
| Format, Host Behavior, and extended LBAs | NVM 1.3 §4.1.2; 4.1.3.7 |
| Namespace creation: format, mask, granularity | NVM 1.3 §4.1.6; 4.1.5.8; 5.8 |
| Metadata transfer and PI placement | NVM 1.3 §2.1.6; 5.2.3; 5.3 |
| Capabilities, opcodes, and status | NVM 1.3 §2.2; 3.1; 3.3 |
| Read/Write data and completion | NVM 1.3 §3.3.4; 3.3.6 |
| Ordering and Compare-and-Write | NVM 1.3 §2.1.2-2.1.3 |
| Normal, power-fail, and multiple atomicity | NVM 1.3 §2.1.4; 4.1.3.4; 5.9 |
| Compare content and verify integrity | NVM 1.3 §3.3.1; 3.3.5 |
| Copy: source descriptors, contiguous destination, partial failure | NVM 1.3 §3.3.2 |
| Copy PI compatibility and transformation | NVM 1.3 §3.3.2.3-3.3.2.4; 5.3.2.5 |
| Dataset Management and three processing limits | NVM 1.3 §3.3.3 |
| Reading deallocated/unwritten blocks | NVM 1.3 §3.3.3.2.1; 4.1.3.3 |
| Write Uncorrectable, Write Zeroes, and whole-namespace zeroing | NVM 1.3 §3.3.7-3.3.8 |
| 16/32/64b Guard and qualified PI | NVM 1.3 §5.3.1; 4.1.5.3 |
| CRC parameters, bit order, and known vectors | NVM 1.3 §5.3.1.1-5.3.1.3 |
| Packing Storage/Reference Tags into Dwords | NVM 1.3 §5.3.1.4 |
| Combining PRACT with PRCHK/STC | NVM 1.3 §2.1.5; 5.3.2-5.3.3 |
| Basic Feature scopes and exceptions | NVM 1.3 §4.1.3.1-4.1.3.4 |
| NVM extensions to AER, SMART, and error records | NVM 1.3 §1.4.2; 4.1.1; 4.1.3.5; 4.1.4.1-4.1.4.4 |
| LBA Status: notices, scans, and recovery | NVM 1.3 §4.1.3.6; 4.1.4.5; 4.2.1; 5.2.1 |
| NVM rules for Sanitize and Media Verification | NVM 1.3 §4.1.7; 5.12 |
| Alignment, granularity, and performance hints | NVM 1.3 §5.2.2 |
| Performance Characteristics attributes | NVM 1.3 §4.1.3.8 |
| Rate Limiting configuration fields | NVM 1.3 §4.1.3.9; 4.1.5.4; 5.10 |
| Hard/Soft modes and token-bucket examples | NVM 1.3 §5.10.1-5.10.2; Appendix A |
| The Rate Limiting log is a capability graph | NVM 1.3 §4.1.4.8; 5.10.3 |
| FDP: placement, RUHs, and observable data | NVM 1.3 §3.2.1; 4.1.4.6-4.1.4.7; 4.1.6.3 |
| NVM units and priorities for Streams | NVM 1.3 §5.2.2.3; 5.13 |
| NVM behavior under ANA and Reservations | NVM 1.3 §5.1; 5.11 |
| NVM alignment constraints for Key Per I/O | NVM 1.3 §5.5; 4.1.5 |
| LBA Migration Queue and change tracking | NVM 1.3 §4.1.8; 5.7 |
| Memory-based resource export template | NVM 1.3 §5.4.1-5.4.1.1 |
| Exported-state length and consistency | NVM 1.3 §5.4.1.2 |
- ELBAF
- Extended LBA Format: pairs with LBAF at the same index and adds PI format and Storage Tag size.
- LBAF
- LBA Format: a description of a logical-block format, including data and metadata sizes.
- AER
- Advanced Error Reporting, the PCIe capability for classifying, masking, and logging link or transaction errors.
- ANA
- Asymmetric Namespace Access: the state of access to a namespace through different controllers.
- FDP
- Flexible Data Placement, a capability connecting data-placement hints with media-reclamation management.
- I/O
- Input/Output, the class of data operations performed on a namespace.
Connect the ideas in this article
1. With NSZE=1000, NCAP=800, and NUSE=600, what question does each value answer?
10.01.NSZE gives the addressable range, LBA 0 through 999; NCAP allows up to 800 allocated logical blocks; NUSE reports 600 currently allocated blocks. These are logical-block counts, so conversion to bytes also needs the data size.
Sources
Source: NVME-NVM-CS-1.3, Rev. 1.3, §2.1.1; 4.1.5.1, printed pages 13-14,85-93, PDF pages 13-14,85-93
2. Does placing Compare and Write next to each other in an SQ prevent intervening modifications?
10.02.Adjacency alone is insufficient. Use a supported fused operation, mark its first and second commands correctly, and satisfy pairing conditions such as matching ranges. Ordinary submission order does not provide that guarantee.
Sources
Source: NVME-NVM-CS-1.3, Rev. 1.3, §2.1.2-2.1.3, printed pages 14-15, PDF pages 14-15
3. Does satisfying the atomic-write size guarantee that the data survives a power loss?
10.03.Atomicity concerns whether a partial update can be observed in the specified circumstances; persistence concerns storage on nonvolatile media. Normal versus power-fail atomicity, boundaries, volatile write cache, and FUA/Flush rules still need separate consideration.
Sources
Source: NVME-NVM-CS-1.3, Rev. 1.3, §2.1.4; 4.1.3.4; 5.9, printed pages 15-21,66-67,165, PDF pages 15-21,66-67,165
Source: NVME-NVM-CS-1.3, Rev. 1.3, §3.3.4; 3.3.6, printed pages 48-51,53-56, PDF pages 48-51,53-56
4. Given expected data, should Compare or Verify be used to check that stored content matches it?
10.04.Compare uses comparison data supplied by the host. Verify checks readability and applicable integrity conditions for the range without returning its data or comparing it against a host-supplied expected payload.
Sources
Source: NVME-NVM-CS-1.3, Rev. 1.3, §3.3.1; 3.3.5, printed pages 27-30,51-53, PDF pages 27-30,51-53
5. Can an all-zero Read establish that the LBAs remain allocated?
10.05.No. Written zero data and zero-valued reads from deallocated blocks can produce the same result. Interpret the read using allocation state, DRB, and whether DULBE is supported and enabled.
Sources
Source: NVME-NVM-CS-1.3, Rev. 1.3, §3.3.3.2.1; 4.1.3.3, printed pages 47-48,66, PDF pages 47-48,66
Source: NVME-NVM-CS-1.3, Rev. 1.3, §3.3.7-3.3.8, printed pages 56-61, PDF pages 56-61
6. Is a data size of 4096 bytes enough to construct the correct I/O buffer?
10.06.No. The active Format Index, metadata size, PI format, and metadata transfer mechanism are also needed. A separate buffer and extended LBAs use different memory layouts.
Sources
Source: NVME-NVM-CS-1.3, Rev. 1.3, §1.1-1.6; 4.1.3.9; 4.1.4.8; 4.1.5, printed pages 9-12,73-75,79-83, PDF pages 9-12,73-75,79-83
Source: NVME-NVM-CS-1.3, Rev. 1.3, §4.1.5.1; 4.1.5.3; 5.6, printed pages 85-94,96-102,160-162, PDF pages 85-94,96-102,160-162
Source: NVME-NVM-CS-1.3, Rev. 1.3, §2.1.6; 5.2.3; 5.3, printed pages 22,129-131, PDF pages 22,129-131
7. Does PRACT=1 turn off every PI check?
10.07.PRACT controls how PI is handled during transfer; it is not a master check switch. PRCHK specifies Guard, Application Tag, and Reference Tag checks, while STC controls Storage Tag checking. Transferred contents also depend on metadata and PI sizes.
Sources
Source: NVME-NVM-CS-1.3, Rev. 1.3, §2.1.5; 5.3.2-5.3.3, printed pages 21-22,141-152, PDF pages 21-22,141-152
8. Why can throughput under a Soft Limit exceed its configured value?
10.08.A Soft Limit permits use of bandwidth or IOPS left unused by other work; resource shortfalls are distributed proportionally to configured limits. A Hard Limit supplies a ceiling. Appendix A token buckets are an illustrative implementation, not a required controller architecture.
Sources
Source: NVME-NVM-CS-1.3, Rev. 1.3, §5.10.1-5.10.2; Appendix A, printed pages 166-168,176-177, PDF pages 166-168,176-177
Comments