I've recently begun supporting Linux installed on devices with built-in nvme ssds. I noticed the device files had an extra number, beyond a number identifying the drive number and the partition number. IDE/SATA/SCSI drives normally only have a drive letter and partition number.

For example: /dev/nvme0n1p2

I got to wondering what the n1 part was, and after a bit of searching, it looks like that identifies an nvme 'namespace'. The definitions for it were kind of vague: "An NVMe namespace is a quantity of non-volatile memory (NVM) that can be formatted into logical blocks."

So, does this act like a partition that is defined at the hardware controller level, and not in an MBR or GPT partition table? Can a namespace span multiple physical nvme ssd's? E.g. can you create a namespace that pools together storage from multiple ssd's into a single logical namespace, similar to RAID 0?

What would you do with an NVME namespace that you can't already achieve using partition tables or LVM or a filesystem that can manage multiple volumes (like ZFS, Btrfs, etc)?

Also, why does it seem like the namespace numbering starts at 1 instead of 0? Is that just something to do with how NVME tracks the namespace numbers at a low level (e.g. partitions also start at 1, not 0, because that is how the standard for partition numbers was set, so the Linux kernel just uses whatever the partition number that is stored on disk is - I guess nvme works the same way?)

2 Answers 2


In NVM Express and related standards, controllers give access to storage divided into one or more namespaces. Namespaces can be created and deleted via the controller, as long as there is room for them (or the underlying storage supports thin provisioning), and multiple controllers can provide access to a shared namespace. How the underlying storage is organised isn’t specified by the standard, as far as I can tell.

However typical NVMe SSDs can’t be combined, since they each provide their own storage and controller attached to a PCI Express port, and the access point is the controller, above namespaces — thus a namespace can’t group multiple controllers (multiple controllers can provide access to a shared namespace). It’s better to think of namespaces as something akin to SCSI LUNs as used in enterprise storage (SANs etc.).

Namespace numbering starts at 1 because that’s how per-controller namespace identifiers work. Namespaces also have longer, globally-unique identifiers.

Namespaces can be manipulated using the nvme command, which provides support for low-level NVMe features including:

  • formatting, which performs a low-level format and allows various features to be used (secure erase, LBA format selection...);
  • attaching and detaching, which allows controllers to be attached to or detached from a namespace (if they support it and the namespace allows it).

Attaching and detaching isn’t something you’ll come across in laptop or desktop NVMe drives. You’d use it with NVMe storage bays such as those sold by Dell EMC, which replace the iSCSI SANs of the past.

See the NVM Express standards for details (they’re relatively easy to read), and this NVM Express tutorial presentation for a good introduction.

  • 1
    I noticed the Linux 'nvme' command, in addition to support for deleting/creating namespaces, also provides concepts of attach/detach, and formatting a namespace (which seems to be separate from the format operation of a filesystem writing to the namespace). Can you provide any information about what those operations are? Commented May 21, 2019 at 21:01
  • 3
    See my updated answer. Commented May 21, 2019 at 21:21
  • if i don't miss any thing,it seems we have no way to change the number of namespace of one nvme disk after it was produced?
    – rpbear
    Commented Jun 23, 2020 at 9:47
  • 1
    @rpbear that depends on the controller, but I suspect that typical laptop/desktop drives and controllers don’t support creating namespaces. Commented Jun 23, 2020 at 9:58

From the horse's mouth:

There are many reasons why host software would want to break up an NVMe SSD into multiple namespaces: for logical isolation, multi-tenancy, security isolation (encryption per namespace), write protecting a namespace for recovery purposes, overprovisioning to improve write performance and endurance and so on.

You can check which features a namespace supports with the nvme command, e.g. via:

# nvme id-ns -H /dev/nvme0n1  
NVME Identify Namespace 1
LBA Format  0 : Metadata Size: 0   bytes - Data Size: 512 bytes
                                         - Relative Performance: 0x2 Good (in use)
LBA Format  1 : Metadata Size: 0   bytes - Data Size: 4096 bytes
                                         - Relative Performance: 0x1 Better

You can check how many namespaces your device supports like this:

# nvme id-ctrl -H /dev/nvme0 | grep nn 
nn        : 1

Looking at NVMe Base Specification 1.4b, it defines valid NSIDs to be greater than 0:

Valid NSIDs are the range of possible NSIDs that may be used to refer to namespaces that exist in the NVM subsystem. Any NSID is valid, except if that NSID is 0h or greater than the Number of Namespaces field reported in the Identify Controller data structure (refer to Figure 251). NSID FFFFFFFFh is a broadcast value that is used to specify all namespaces. An invalid NSID is any value that is not a valid NSID and is also not the broadcast value.

(Section 6.1.2 Valid and Invalid NSIDs)

Having 0 as an invalid value has the advantage that you can use 0 to terminate an array of namespace IDs (cf. Section 4.10 Namespace List).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .