FDP Placement Handles Add a New Map Inside an NVMe Namespace

A logical address and a placement choice answer different questions

A storage proposal can name separate NVMe namespaces and an FDP-capable SSD while leaving its data-grouping policy unresolved. The namespace identifies the logical address space; the placement choice concerns how submitted data is grouped beneath that address space.

Samsung's FDP explainer describes continued logical block addressing with optional placement information. The drive retains logical-to-physical mapping, garbage collection and bad-block management. The host can express grouping intent without taking over every media-management responsibility.

That division matters when assessing an offer. Recognizing the drive and reading or writing its logical blocks does not demonstrate that the offered software communicates the buyer's intended grouping. The additional question is which software component connects the data's expected lifetime to a placement choice.

References: [FD2]

Follow the local index to the resource it selects

Samsung's whitepaper defines a reclaim unit, or RU, as a managed set of NAND blocks, and a reclaim group, or RG, as a collection of RUs. A reclaim-unit handle, or RUH, is a device write resource referencing an RU in a reclaim group.

A placement handle indexes the namespace's list of accessible RUHs. The placement identifier combines that local handle with a reclaim-group selection. The namespace, local index and selected resource are therefore different identities.

The August 2023 NVM Express presentation illustrates the lookup explicitly: Namespace A's placement handle 1 selects RUH 2 in its example. It also shows that when the referenced RU fills, the controller can make that RUH reference another RU in the same group. A handle is consequently not a permanent physical-address label.

For a buyer, a list of local handle numbers leaves the important relationship incomplete. The resource mapping explains whether two data classes select distinct RUHs or converge on the same one.

References: [FD1][N1]

FD-331: two handle-zero labels, two different destinations

FD-331 is a fictional mapping within one endurance group and one reclaim group. Namespace A's local handle 0 selects RUH 7, and A's local handle 1 selects RUH 9. Namespace B's local handle 0 also selects RUH 9. Stipulate that the referenced RUs differ and have enough remaining room for all the following data, with no RU change or relocation during this example.

A submits four equal toy payload units through its handle 0 and two through its handle 1. B submits three through its handle 0. The supplied mappings group four units through RUH 7 and 2 + 3 = 5 through RUH 9. The original host payload is still 4 + 2 + 3 = 9 units.

Comparing only the two handle-zero labels would miss that A:0 and B:0 select different RUHs. Comparing namespace names alone would miss that A:1 and B:0 select the same RUH. The relevant equivalence is the resolved resource, with the reclaim group fixed here.

Suppose the four A:0 units are intended to remain useful much longer than the other five. This mapping expresses that grouping across namespace boundaries: A contains both lifetime classes, while B contributes to the same class as part of A. It could therefore fit that stipulated policy better than a simple one-group-per-namespace assumption.

The numbers count original payload assigned through each resource. They establish no RU capacity in bytes, extra usable storage, internal write quantity or performance result. This is an interpretation of an invented mapping, not an observation of a device.

References: [FD1]

Useful grouping follows when data becomes obsolete

Samsung's whitepaper connects FDP placement to data with similar lifetimes becoming invalid at around the same time. Grouping data that becomes obsolete together can leave fewer still-needed companions to preserve when reclaiming that space. Mixing long-lived contents with rapidly replaced contents leaves the longer-lived data to be retained. This is the policy's rationale; the fictional mapping supplies no measurement of its benefit.

In FD-331, the proposed distinction is how long the two classes remain useful. A namespace-only summary would hide A's two different lifetimes. Conversely, forcing each namespace into an exclusive group would separate the five short-lived units even though the stipulated policy treats them alike.

The buyer's task is to determine whether the offered software can express the relevant distinction for the actual workload. A supplier saying it uses several handles has supplied a mechanism count, but has not explained what determines a data class, which class selects which resource, or why that choice matches the expected replacement or deallocation pattern. A mistaken lifetime classification remains possible even with a correctly resolved handle.

References: [FD1]

Initial segregation leaves a different promise after relocation

Samsung distinguishes Initially Isolated and Persistently Isolated RUHs. With initial isolation, data submitted through different RUHs is segregated on the host write, but later controller garbage collection can mix it. Persistent isolation maintains segregation from data associated with other RUHs through the data's lifetime; it does not require the data to stay in its original RU.

Apply that distinction to FD-331. Its initial four-versus-five grouping does not by itself establish what happens after controller relocation. If continued separation between those groups matters, the offer needs to identify the applicable RUH types and their supported behavior.

Even persistent isolation would not separate A:1 from B:0: the fictional mapping deliberately sends both through RUH 9. A promise about separation between different RUHs cannot supply separation between two users of the same RUH.

Here, isolation describes media placement. It does not establish access control, cryptographic separation or tenant-security isolation. Those requirements need their own evidence.

References: [FD2]

Read the software commitment behind the FDP label

Samsung's whitepaper describes an optional placement directive. With FDP enabled, a write that omits it uses the RUH associated with that namespace's placement handle 0, and the SSD selects the reclaim group. That default route does not show that the software distinguishes multiple lifetime classes within the namespace.

Consider an offer whose evidence stops at an FDP-supported component line. That line leaves open whether the selected software submits placement intent at all. A second offer might identify the supported device and software versions and the FDP configuration enabled for the relevant endurance group, explain its lifetime classes, resolve those classes through each namespace's handle list, and state whether segregation persists through controller relocation. The second explanation addresses the buying question more directly; it still needs applicable evidence for any promised performance or endurance result.

The responsible software layer could sit below the application. The useful requirement is a coherent explanation of the offered path, from the component that knows the grouping policy to the placement information reaching the device. An application name or operating-system compatibility statement alone does not establish that path.

Use the linked garbage-collection guide for the cost of preserving valid data, the over-provisioning guide for reserved-capacity accounting and the zoned-NVMe guide for zone write rules. FDP's distinct question is who supplies placement intent, which resources it selects and how long the stated segregation lasts.

References: [FD1][N1]

Carry the selected equipment into its physical installation

If the storage decision introduces servers or storage equipment into a deployment, Leviathan's rack-and-stack service can discuss agreed equipment mounting, IT cabling, labeling and physical handoff records. The service and its project inquiry are linked below.

Share a nonconfidential equipment summary, released rack and connection plans, site constraints and required physical records. Keep the appointed storage and software owners identified for FDP policy and system configuration; the physical installation discussion concerns the selected equipment package.

References: [L1]