NVMe FDP: placement handles are not physical addresses

12 October 2026 / Specification and research review

Flexible Data Placement lets software influence which writes share reclaimable media. It does not turn logical block addresses into NAND addresses, and enabling it does not demonstrate a performance or endurance gain.

Separate lifetimes, not just addresses

When short-lived and long-lived data share a cleaning unit, reclaiming space may require copying the surviving data. FDP gives host software a way to group writes using knowledge of their expected lifetimes. The controller still handles address translation, garbage collection and bad blocks. Samsung's architecture explanation describes this division of responsibility; its reported benefits belong to its particular workloads and devices. [7, sections 2-6]

This connects hot/cold data separation to an interface. Here "hot" concerns updates, not temperature. See also over-provisioning and SSD mapping caches.

Three objects that should not be conflated

Terminology from NVM Express Base 2.1, not a physical layout diagram. [1]
Object	Meaning	Not equivalent to
Reclaim unit (RU)	Storage within a reclaim group that can be erased independently of other RUs.	A host LBA interval or ZNS zone.
Reclaim unit handle (RUH)	A controller resource referencing one RU in each reclaim group.	One immutable physical location.
Placement identifier (PID)	A reclaim group identifier plus a namespace-scoped placement handle.	An LBA or a raw RUH identifier.

The namespace's placement-handle mapping resolves to an endurance-group RUH. In the official worked example, the controller fills one RU and moves that handle's reference to an empty RU. The same handle can therefore select a different underlying destination later. [2, slides 17-22]

The NVM Command Set 1.1 status descriptor also separates nominal capacity from remaining capacity: RUAMW is a count of logical blocks available for writes, not bytes. Interpret it with the namespace's LBA size. A zero EARUTR reports no time estimate; it does not mean the unit has expired. [3, Figure 20]

FDP is not a ZNS interface

FDP retains random writes and overwrites. ZNS imposes zone-oriented write and lifecycle constraints. The official comparison describes FDP as compatible with existing NVM behavior, with optional host participation. [2, slides 6 and 23] The ZNS resource guide explains why open-zone and active-zone limits are separate questions.

Isolation needs qualification too. Samsung's v4 guide distinguishes Initially Isolated handles, whose relocated data may mix with data from other handles of that type in the same group, from Persistently Isolated handles, which preserve same-handle segregation during relocation. Check the reported type before promising persistent separation. Segregation is not a guarantee of independent throughput or latency. [4, section 4.1.1]

Placement is not a persistence acknowledgement. Evaluate crash durability separately from placement efficiency, using the power-loss protection and fsync error guides.

What the papers actually establish

Allison et al. tested CacheLib on two machines, each using a 1.88 TB Samsung PM9D3 with FDP-capable firmware. Their KV-cache example used 50% device utilization and a 4% small-object cache (SOC); device-level write amplification fell from 1.3 to 1.03. With full utilization and SOC expanded to 64%, FDP amplification rose to 2.5. Capacity allocation matters as well as separating lifetimes. [9, sections 6.1-6.5]

Those are trace-replay results, not universal product specifications. The paper samples byte-counter intervals of ten minutes. Its carbon estimates use a lifecycle model, and GC-event counts are an energy proxy, not direct power measurements. [9, sections 6.1 and 6.6]

Song et al.'s WARP study tested two commercial SSDs from different vendors, with eight handles each; one device failed during testing, limiting its results. Under the tested F2FS workloads, about 99% of user-data writes received the same warm hint. Multiple available handles therefore did not ensure useful classification. [8, sections 3.1-3.4, Figure 11]

WARP's emulator exposes cross-handle GC pressure and shows that persistent isolation can cost more amplification when spare capacity is scarce. This is a modeled policy trade-off, not a demonstrated advantage of every shipping device. [8, sections 5.2-5.3]

Hesela's synthesis: distinguish four questions: does the device accept placement hints, does the application classify writes usefully, does relocation preserve segregation, and do measured end-to-end outcomes improve? A positive answer to one does not establish the others.

Measure the policy, not the feature flag

Samsung's guide evaluates interval write amplification using changes in media-written and host-written counters. Use the same time interval and accounting scope, with a positive host-written denominator. [4, section 6.1, p. 12] A lifetime ratio cannot isolate a new placement policy, and device WAF is not application-level amplification.

For a future comparison, preserve device, firmware, capacity, preconditioning, data volume, address distribution and workload mix. Record the chosen grouping policy, throughput and latency distribution as well as byte counters. Compare the same logical workload with and without useful placement. These are proposed controls, not an experiment performed here.

The xNVMe tutorial exposes configuration, RUH usage, statistics and event logs, plus status and update operations. It also warns that changing FDP enablement involves namespace-management prerequisites. Do not treat initialization recipes as harmless checks on a drive containing data. [5]

What emulation can establish

QEMU provides FDP command-interface emulation, configurable reclaim groups and handles, and a nominal RU size. Its documentation explicitly notes that configuring FDP forces its mode on, a deviation from the specification. [6] Passing that interface test does not measure real NAND behavior. The 2023 NVM Express presentation explicitly separates QEMU host-stack validation from WAF or performance simulation. [2, slide 7]

Practical conclusion: first verify the interface and mappings, then evaluate the placement policy on the intended device and workload. Neither an emulator trace nor a vendor example establishes a universal WAF of 1.

Primary sources and scope

Sources checked 12 October 2026. Terminology is pinned to Base 2.1 and NVM Command Set 1.1, not presented as the latest specification survey. No hardware benchmark, endurance measurement or paper reproduction was performed. Source works retain their own rights.

Machine-readable entry: NVMe FDP.