NVMe's Transfer-Size Field Is Not a Count of Disk Blocks

Decode the exponent and its memory-page unit first

A supplier's statement that a controller has MDTS 5 is incomplete as a byte limit. Five is the encoded exponent. It supplies a multiplier of 2^5 = 32, whose unit must still be identified.

Microsoft's NVME_IDENTIFY_CONTROLLER_DATA reference defines MDTS in minimum memory-page units. Its NVME_CONTROLLER_CAPABILITIES reference defines that minimum supported host page size as 2^(12 + MPSMIN) bytes. For nonzero MDTS, the resulting relationship is maximum bytes by this field = 2^MDTS x 2^(12 + MPSMIN).

Use the controller's supported minimum, rather than substituting a currently configured host memory-page size. The field definition names CAP.MPSMIN. A larger page selected elsewhere does not change that reference unit.

The namespace's logical block size answers a different question: how many data bytes one addressed logical block contains. A NAND page and a filesystem allocation cluster describe other layers. None can replace the minimum host memory-page unit in this calculation. The related sector-format guide develops the addressing distinction.

References: [M1][M2]

Work the 128 KiB example before counting logical blocks

Consider original fictional case MT-285. Stipulate MDTS = 5 and MPSMIN = 0, with no metadata. Compare two alternative namespace formats containing 512 or 4,096 data bytes per logical block. These are teaching inputs, without a claimed product or supported format change.

The minimum memory page is 2^(12 + 0) = 4,096 bytes. The MDTS multiplier is 2^5 = 32. Their product is 32 x 4,096 = 131,072 bytes. Using 1 KiB = 1,024 bytes, this is 128 KiB.

Now express that same span in the two stipulated logical-block units. At 512 bytes per block, 131,072 / 512 = 256 blocks. At 4,096 bytes per block, 131,072 / 4,096 = 32 blocks.

The counts differ eightfold because the blocks differ eightfold in size. The MDTS-derived byte ceiling remains 131,072 bytes in both cases. Multiplying the 256-block count by 4,096 bytes would produce 1,048,576 bytes, but it would silently carry a count from the 512-byte case into the other format.

This arithmetic measures the data span against one field's ceiling. It supplies no observation of application requests, commands submitted or media operations.

References: [M1][M2][U1]

The same MDTS can encode a different byte ceiling

Change only the fictional minimum-page input to MPSMIN = 1. The supported minimum becomes 2^(12 + 1) = 8,192 bytes. With MDTS still 5, the result is 32 x 8,192 = 262,144 bytes, or 256 KiB.

This alternative has the same exponent as MT-285 and twice the byte ceiling. Comparing the MDTS numbers alone would miss that difference. Comparing only the logical-block formats would also miss its cause: the changed quantity is the controller's minimum memory-page unit.

The example changes a stipulated capability input between fictional controllers. It gives no instruction to change a host page size or namespace format. For an actual offer, retain both encoded values and the supplier's decoded byte quantity together.

References: [M1][M2][U1]

Handle zero as a special value

MDTS = 0 does not follow the ordinary exponent calculation. Microsoft describes it as no transfer-size restriction; the Base 2.1 definition likewise assigns zero a special no-maximum meaning for this field. Treating it as 2^0 times one minimum page would impose a limit that the definition does not state.

A claim of unrestricted I/O would go further than that field meaning. Other command, host and transport constraints may still apply. Base 2.1 also excludes commands that transfer no data between host-accessible memory and the controller from MDTS applicability. The relevant command's own rules still matter.

References: [M1][N1]

Keep metadata accounting attached to its specification

The examples deliberately contain no metadata. When metadata is present, the accounting needs the applicable definition and controller attributes.

Microsoft's March 13, 2023 reference says the restriction includes metadata interleaved with logical-block data. NVM Express Base Specification 2.1, dated August 5, 2024, adds an explicit distinction in Figure 312: with CTRATT.MEM cleared, interleaved metadata counts toward MDTS; with that bit set, metadata length is excluded.

Thus the older API prose cannot supply a universal rule for every controller and specification edition. Identify the applicable metadata treatment before translating a transfer ceiling into an allowed user-data block count. The 2.1 passage cited here is a versioned definition, without a claim that 2.1 is the newest edition.

References: [M1][N1]

Judge the claim at the boundary it actually describes

For a proposal quoting a maximum transfer, ask the storage supplier to identify the controller and applicable firmware, the relevant specification and command scope, MDTS, CAP.MPSMIN and the resulting byte quantity. Include the namespace's logical block format when the claim is also expressed as a block count. For transfers with metadata, retain its accounting basis.

The useful comparison is then concrete. In MT-285, a stated 128 KiB ceiling and 32 blocks of 4,096 data bytes agree. A statement that the same inputs permit 256 such blocks disagrees with the byte calculation. The missing or inconsistent unit is enough to return that interpretation for clarification; it does not establish a hardware fault.

The host path adds another boundary. Linux 6.12's stable ABI documentation distinguishes the hardware transfer maximum from the block layer's allowed filesystem-request maximum, which must fit the hardware maximum. This is a documented example of separate limits, without an inference about an offered system's values.

A decoded ceiling alone cannot establish the host's actual request splitting, best request size, throughput, latency or atomic-write allowance. Those claims need evidence for their own behavior and workload. Use the linked queue guide for command organization, the performance guide for IOPS, throughput and latency, and the atomic-write guide for indivisibility and persistence.

References: [K1]

Connect an approved storage choice to the physical refresh

If the storage and platform owners' assessment leads to an approved equipment change, Leviathan's Hardware Refresh & Physical Support service can discuss the surrounding replacement, recabling and physical records. Its service page and project inquiry are linked below.

Share a nonconfidential summary of the equipment, approved replacements, site, change window, appointed supplier and required physical handoff. Identify the owners of storage configuration, data handling and return to service alongside the physical scope. This turns the approved equipment choice into a defined installation discussion.

References: [L1]