An NVMe Namespace is a logical partition of NVMe storage capacity — similar to a LUN in traditional SANs — that appears as an independent block device with its own ID and capacity allocation.
An NVMe Namespace is identified by a 32-bit Namespace ID (NSID) within an NVMe controller. NSID 1 is the first namespace and NSIDs are allocated sequentially. Each namespace has its own Namespace Size (total capacity in logical blocks), Namespace Capacity (maximum number of logical blocks that may be in use), Namespace Utilization (currently allocated blocks for thin-provisioned namespaces), and a 128-bit Namespace Globally Unique Identifier (NGUID) or EUI-64 for unique identification across systems.
The NVMe specification supports several namespace features that enable advanced storage behaviors. Namespace sharing allows a single namespace to be attached to multiple controllers simultaneously — enabling active-active shared storage when paired with Asymmetric Namespace Access (ANA) groups that define path optimality. Namespace management commands (Create, Delete, Attach, Detach) allow dynamic provisioning of namespaces without power cycling the device, equivalent to LUN provisioning in traditional SANs.
In NVMe-oF (including NVMe/TCP) environments, namespaces are exposed over the fabric through NVMe subsystems. An initiator that connects to an NVMe/TCP target and issues an Identify Namespace List command receives a list of all namespaces attached to that subsystem. The host OS then creates a block device for each namespace (e.g., /dev/nvme0n1 for the first namespace of the first controller). From the host perspective, a fabric-attached NVMe namespace is indistinguishable from a locally attached NVMe device.
Namespaces are the fundamental unit of storage allocation in any NVMe-oF deployment. When provisioning storage over NVMe/TCP, an administrator creates namespaces on the target subsystem and attaches them to the subsystem's controllers. The initiator then discovers and accesses those namespaces as block devices. In Kubernetes environments using NVMe/TCP storage backends, each PersistentVolume typically maps to a single NVMe namespace presented through the NVMe/TCP target.
/dev/nvmeXnY on Linux hostsThe NVMe Namespace is conceptually analogous to the Logical Unit Number (LUN) in traditional SCSI/FC/iSCSI SANs, but with important improvements. NVMe namespaces have globally unique 128-bit identifiers, whereas LUN IDs are only locally significant within a target port. NVMe supports thousands of namespaces per subsystem with standardized dynamic provisioning commands, whereas LUN management in traditional SANs often requires vendor-specific management software. The namespace abstraction also supports advanced features like Namespace Thin Provisioning and Copy commands (NVMe Simple Copy) that have no direct SCSI equivalent.