NVMe Namespaces Explained: Not the Same as Partitions

Plug an NVMe drive into a Linux server and it appears as /dev/nvme0n1. The n1 on the end is the namespace, and on most drives it is the only one there will ever be.

On enterprise NVMe drives it does not have to be. Namespaces are a drive-level capability that has no equivalent on SATA, and they are useful for over-provisioning, sector size changes, tenant separation and secure erase in ways that partitions cannot match.

What a namespace is

A namespace is a portion of an NVMe drive's capacity that the drive itself presents to the host as an independent block device.

The important word is itself. This is not the host dividing up a device it has been given. It is the drive being told to expose its flash as one device, or several, each with its own capacity, its own sector size and its own identifier.

The closest familiar equivalent is a LUN on a SAN array. The array owns the storage and decides what to present; a host sees whatever it is offered and has no visibility of the rest.

How this differs from a partition

The distinction matters because the two look similar from the operating system and behave very differently underneath.

A partition is host-side bookkeeping. The drive hands over its whole capacity, the host writes a table at the start describing how it has divided that up, and every partition shares the drive's single sector size and single security domain. Wipe the partition table and the data is still there.

A namespace is drive-side. The drive knows about it, enforces it, and can format or erase one without touching another. Each namespace can carry a different sector size. A host given one namespace cannot address capacity in another, because as far as the controller is concerned that capacity belongs to a different device.

Practically, a partition divides what the host was given. A namespace decides what the host is given in the first place.

Not every drive supports more than one

Worth establishing before planning around it.

The NVMe specification permits multiple namespaces but does not require them. Consumer and client drives typically support exactly one, fixed at the full capacity, and offer no namespace management at all.

Enterprise drives generally support namespace management, but the maximum count varies by model, and some support creating namespaces while others only allow reformatting the single existing one. The drive reports its maximum number of namespaces in its identify data, which is where to check rather than in marketing copy.

If you are specifying drives for a design that depends on multiple namespaces, confirm the count against the specific part number. This is a real differentiator between otherwise similar drives.

What namespaces are actually used for

Five applications, roughly in order of how often they come up.

Over-provisioning. Creating a namespace smaller than the drive's capacity leaves the remainder unallocated, and the controller treats it as spare area. This is the cleanest way to increase over-provisioning, because the drive knows definitively that the capacity is unused rather than inferring it from unpartitioned space. Our over-provisioning guide covers what that reserve buys.

Sector size selection. A namespace is formatted with a logical block size, commonly 512 bytes or 4096. Many enterprise NVMe drives ship formatted at 512 for compatibility but perform better at 4096, and some support additional metadata bytes per block for end-to-end protection. Changing this is a namespace format operation, and it destroys the data. Our sector format guide covers why the choice matters.

Separation between tenants or workloads. Two namespaces on one drive are separate devices to the host. In virtualised and multi-tenant environments this gives cleaner separation than partitioning, and each namespace can be erased independently when a tenant leaves.

Independent secure erase. A cryptographic erase can be performed per namespace. You can destroy one dataset on a drive while leaving another intact, which partitions cannot offer. Our data sanitisation guide covers where that fits in a disposal process.

Shared access across controllers. A namespace can be attached to more than one controller, which is how dual-port NVMe drives present the same storage down two paths for redundancy — the same principle as dual-port SAS and multipath.

Reading the device names

The naming trips people up because it encodes two separate things.

In /dev/nvme0n1, nvme0 is the controller and n1 is namespace ID 1 on it. A second drive is nvme1n1 — a different controller, its own namespace 1.

A second namespace on the first drive is nvme0n2. A partition inside that namespace is nvme0n2p1.

So nvme0n1 and nvme0n2 are two devices on the same physical drive, while nvme0n1 and nvme1n1 are two different drives. Worth getting right before running anything destructive, because the difference is one character.

The operations, and what they destroy

Namespace management is handled by the drive through admin commands, exposed by the standard NVMe command-line tooling on Linux and by vendor utilities elsewhere.

Create defines a new namespace of a given size and format out of the drive's unallocated capacity. It does not appear to the host until attached.

Attach and detach control which controllers can see a namespace. Detaching hides it from the host without destroying it.

Delete removes the namespace and returns its capacity to the unallocated pool. The data is gone.

Format changes the sector size or performs a secure erase on an existing namespace. Also destructive.

Two cautions that are worth stating plainly. To reclaim capacity from an existing full-size namespace and create smaller ones, you generally have to delete the existing namespace first, so this is a wipe-and-rebuild operation rather than a resize. And the drive typically needs to be idle and unmounted, with the host not holding the device open, or the commands will fail or behave unpredictably.

Where this fits against a RAID controller

Worth flagging, because it changes what is available to you.

Namespaces are a property of the drive and the host talking NVMe directly. Where NVMe drives sit behind a hardware RAID controller or a storage abstraction layer, the host usually sees the controller's virtual disks rather than the drive's namespaces, and namespace management is either unavailable or handled by the controller.

This is one of the reasons software-defined storage and direct-attached NVMe designs give more control over drive behaviour than a traditional RAID controller does, and it sits alongside the controller versus HBA question.

Sourcing

We supply enterprise NVMe SSDs in U.2, U.3 and M.2 across read-intensive, mixed-use and write-intensive tiers, with the exact manufacturer part number and condition stated on every line.

If your design depends on multiple namespaces or a specific sector size, tell us and we will confirm the capability against the part number before quoting. Send a bill of materials through the bulk quote page or email sarah.jane@techsellerusa.com.

Common questions

Tell us what the design needs and we will confirm namespace support against the part number.