Persistent Identifiers for Storage Devices

The SCSI identifier ecosystem uses the following priority order for identifiers from VPD pages 0x83 and 0x80. This ordering is defined by the sg3_utils rules (63-scsi-sg3_symlink.rules); the scsi_id helper (from systemd) uses a compatible but simpler scheme that only distinguishes NAA Registered Extended and NAA Registered explicitly, treating all other NAA subtypes at the same priority:

The resulting symlink looks like:

For example: /dev/disk/by-id/scsi-36001405d27e27d30e2e4f35a08a1c7f0

When a NAA identifier is available, udev also creates a wwn- symlink using the NAA subtype and identifier directly, prefixed with 0x: /dev/disk/by-id/wwn-0x<naa_subtype><id>.

For example, the scsi- and wwn- symlinks for the same device:

The primary scsi-<ID_SERIAL> symlink is created by 60-persistent-storage.rules, which runs scsi_id to select the best identifier. When the sg3_utils package is installed, additional rule files extend this behavior. The sg3_utils rules are configured through two udev variables defined in 00-scsi-sg3_config.rules: .SCSI_ID_SERIAL_SRC controls how ID_SERIAL is set (for consumption by other udev rules, event listeners, and udev database readers), and .SCSI_SYMLINK_SRC controls which additional symlinks are created. To change these variables, copy the file from /usr/lib/udev/rules.d/ to /etc/udev/rules.d/ and edit the copy.

ENV{.SCSI_ID_SERIAL_SRC} (61-scsi-sg3_id.rules): If scsi_id did not set ID_SERIAL (e.g., because VPD queries failed), these rules act as a fallback, setting ID_SERIAL from identifiers obtained by sg_inq (a command-line utility from the sg3_utils package that sends SCSI INQUIRY commands to a device and parses the response, including VPD pages; when called with --export, it outputs key-value pairs suitable for consumption by udev rules; it can also parse pre-cached inquiry data from sysfs with --inhex without sending commands to the device). Note that because udev evaluates SYMLINK+= immediately, this fallback ID_SERIAL does not create a scsi- symlink (that rule in 60-persistent-storage.rules has already been evaluated). It is available for other consumers that read ID_SERIAL from the udev database later. The variable controls which ambiguous identifier types the fallback may use:

NAA (except Local), EUI-64, and SCSI Name String are always considered unconditionally, regardless of this setting. NAA Local, Vendor-Specific, and Serial Number are disabled because they lack reliable uniqueness guarantees. Enabling them for ID_SERIAL can cause data corruption with multipath if identifiers collide.

ENV{.SCSI_SYMLINK_SRC} (63-scsi-sg3_symlink.rules): Creates additional per-identifier-type symlinks independently of scsi_id. You may see multiple by-id symlinks for the same device, each using a different identifier type:

Symlinks for NAA (except Local), EUI-64, and SCSI Name String are always created unconditionally. The remaining types (same letters: T, L, V, S) are only created if listed in .SCSI_SYMLINK_SRC. By default it is empty, so no additional ambiguous symlinks are created.

These additional symlinks are useful when you want to explicitly reference a specific identifier type rather than relying on automatic priority selection.

Depending on how the SCSI device is attached, additional symlinks may be created beyond the primary scsi- and wwn- symlinks. These fall into two categories: by-id symlinks (device-intrinsic, survive port changes) and by-path symlinks (path-based, change if the device is moved to a different port or controller).

Additional by-id symlinks (from 60-persistent-storage.rules, always available):

by-path symlinks (generated by the path_id udev builtin, always available). PCI-attached buses are prefixed with pci-<DBDF> (where DBDF stands for Domain:Bus:Device.Function, e.g. 0000:04:00.0, the standard PCI address format):

Additional by-path symlink from sg3_utils (requires the sg3_utils package):

The full by-path name encodes the entire hardware topology from the root bus to the device. Network-attached (iSCSI) and virtual (Hyper-V) transports use their own top-level prefix instead of pci-<DBDF>.

Note that by-path symlinks encode the transport path to the device, not an intrinsic device property. If you move the device to a different port or controller, the by-path symlink changes.

The kernel chooses the best available identifier in the following priority order:

The resulting symlink looks like:

For example: /dev/disk/by-id/nvme-eui.0000000000000000707c189d7f388728

In addition to the primary by-id symlink based on the wwid, udev also creates a secondary symlink based on model, serial number, and namespace ID:

For example: /dev/disk/by-id/nvme-ACME_X1000_A1B2C3D4E5F6_1

NVMe devices also get a by-path symlink based on the PCI slot address (DBDF) and namespace ID:

For example: /dev/disk/by-path/pci-0000:04:00.0-nvme-1

UUID (Universally Unique Identifier). The highest-priority identifier in the kernel’s selection order. Defined by RFC 4122 (and its successor RFC 9562), 128 bits, and globally unique when properly generated. Introduced in NVMe 1.3 as part of the Namespace Identifier Descriptor list. Exposed in sysfs as /sys/block/nvme*n*/uuid.

NGUID (Namespace Globally Unique Identifier). A 128-bit NVMe-native identifier introduced in NVMe 1.2. The spec requires it to be globally unique, but there is no external enforcement mechanism; it is up to the vendor. Vendors typically embed an IEEE OUI (Organizationally Unique Identifier) prefix. Exposed in sysfs as /sys/block/nvme*n*/nguid.

EUI-64 (Extended Unique Identifier, 64-bit). An IEEE-standardized 64-bit identifier. The 64 bits are split into a 24-bit OUI prefix (assigned by IEEE to the manufacturer) and a 40-bit extension identifier (assigned by the manufacturer to individual devices). Introduced in NVMe 1.1. Exposed in sysfs as /sys/block/nvme*n*/eui.

Fallback (Model+Serial). When none of the above identifiers are available or when they are flagged as bogus, udev falls back to constructing a symlink from the drive’s model, serial number, and namespace ID. This fallback is the least reliable because serial numbers and model strings are free-form ASCII fields with no formal uniqueness guarantee, but it does at least give you something.

The identifier story sounds clean in theory. In practice, some NVMe drive firmware gets it wrong. Here are real issues that have affected production systems:

Duplicate identifiers across namespaces. Some NVMe SSDs that support namespace management are not able to properly generate unique IDs for each namespace. When the kernel detects this, it logs:

The affected namespace is not registered and becomes invisible to the system.

Identifiers changing unexpectedly. Some controllers momentarily present stale identifiers during namespace operations like nvme attach-ns, triggering:

Other drives report changed identifiers after resuming from suspend.

Bogus identifiers. Some drives report identifiers that are all zeros or otherwise non-unique. The Linux kernel maintains a quirk list (the nvme_id_table[] array in drivers/nvme/host/pci.c, with flags defined in drivers/nvme/host/nvme.h) for known-bad hardware. Two quirks directly affect identifiers:

The quirk granularity problem. NVMe drives are physically connected via PCIe (PCI Express), the high-speed hardware bus used to connect NVMe drives (and other devices like GPUs and network cards) to the system. The kernel’s quirk mechanism identifies drives by their PCIe vendor ID (VID) and device ID (DID) pair. But a single device ID can span many drive models and firmware versions. For example:

Quirking an entire device ID as bogus can unnecessarily degrade the identifier quality for drives that actually report valid IDs.

Dynamic quirk configuration. A kernel change introduced in Linux 7.0 adds support for configuring NVMe quirks at module load time via a quirks module parameter, without requiring kernel recompilation. This is especially useful for situations where the built-in quirk table does not cover a specific drive or where a quirk needs to be disabled for a drive that is incorrectly listed. The parameter format is:

For example, to enable the bogus_nid quirk for a specific vendor and device ID:

Prefixing a quirk name with ^ disables it, which allows overriding a built-in quirk that is causing problems on a particular system. Multiple entries are separated by -. This can be set persistently via kernel command line or modprobe configuration, providing a practical workaround without waiting for a kernel update to add or remove a static quirk entry.

Impact on upper layers. When identifiers change (e.g., after a kernel update applies a new quirk), upper-layer software that records device identity may fail to find the underlying device. This can cause boot failures or service disruptions if the affected device holds the root filesystem or other critical data. In such cases, the upper layer needs to refresh its device ID records to match the new identifiers.

This section covers virtio-blk devices only. Virtio-scsi devices appear as regular SCSI /dev/sd* devices and are covered by the SCSI section above.

At the hardware level, the serial is retrieved via the VIRTIO_BLK_T_GET_ID command (a 20-byte string assigned by the hypervisor). The kernel exposes it as /sys/block/vd*/serial, and udev rules read it directly to create the symlink. Its reliability depends entirely on the hypervisor configuration. If no serial is assigned, no symlink is created.

At the hardware level, the name and serial come from the CID (Card Identification) register, a 128-bit hardware register containing manufacturer ID, product name, serial number, and manufacturing date. The parsed CID fields name, serial, date, manfid, oemid, hwrev, fwrev, and the raw CID register cid, are accessible under /sys/block/mmcblk*/device/. Udev rules read name and serial directly to create the symlink. Typically reliable for the lifetime of the embedded device, though cheap SD cards may have non-unique serials.

The by-path format varies: platform-<addr> for SoC-integrated controllers, pci-<DBDF>-…​ for PCI-attached card readers, or pci-<DBDF>-usb-…​ for USB card readers.

At the hardware level, the UUID comes from the NVDIMM Label Storage Area (LSA), persistent metadata stored on the DIMM in the original EFI label format (defined in the UEFI specification, discovered by the kernel via the ACPI NFIT, NVDIMM Firmware Interface Table, an ACPI table that describes the platform’s persistent memory topology) or the newer CXL (Compute Express Link) label format (defined in the CXL 2.0 specification for CXL-attached persistent memory). Both formats store a UUID per namespace; the kernel handles either transparently. The kernel exposes it as a uuid sysfs attribute, and udev rules read it directly to create the symlink. Generally reliable.

The old cciss driver presented logical volumes as /dev/cciss/c*d* with its own block device interface, separate from the SCSI subsystem. (The newer hpsa driver, which replaced cciss for newer controllers, presents devices as SCSI /dev/sd* instead.) Despite not being a SCSI device, 60-persistent-storage.rules invokes scsi_id to query the controller for identification:

The /dev/cciss/ compat name is only created when the sg3_utils package is installed; it provides backward-compatible device paths for tools that still expect the old naming.

Device-Mapper (DM) devices have names and, optionally, UUIDs attached to them. The DM name is always present. The DM UUID is optional for the DM device as such, but known subsystems like LVM, LUKS, and dm-multipath always set it. These subsystems derive the DM UUID from identifiers stored in their own on-disk metadata (LVM metadata on PVs, LUKS header, multipath configuration). Note that device-mapper identifiers are not tied to hardware and can be changed by the subsystem, though the device may need to be reactivated to take the new identifiers into account.

To inspect a device-mapper device’s name, UUID, and state, use dmsetup info.

Generic DM symlinks (created for all DM devices):

The DM UUID format and additional symlinks depend on the subsystem creating the DM device:

LVM: LVM sets the <dm_uuid> to LVM-<vg_uuid><lv_uuid>, where <vg_uuid> and <lv_uuid> are the VG and LV UUIDs (viewable with lvs -o+vg_uuid,lv_uuid). LVM UUIDs are not RFC 4122 UUIDs. They use the format xxxxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx (seven groups of alphanumeric characters from the set [0-9a-zA-Z]). Note that lvs displays them with these dashes, but the DM UUID concatenates them without dashes. The pv_uuid can be found with pvs -o+pv_uuid (and here the dashes are present in the symlink as reported by pvs):

For example:

LUKS: cryptsetup sets the <dm_uuid> to CRYPT-LUKS<ver>-<luks_uuid>-<dm_name>, where <ver> is 1 or 2 (depending on the LUKS version used) and <luks_uuid> is the RFC 4122 UUID stored in the LUKS header:

For example:

dm-multipath: multipathd sets the <dm_uuid> to mpath-<wwid>, where <wwid> is the SCSI identifier (from scsi_id) of the underlying paths. When the wwid is NAA-based, a wwn- symlink is also created using the same identifier in WWN format:

For example:

Since the multipath device and its underlying paths share the same WWN, there would be a conflict over the wwn- symlink. Multipath resolves this by setting a higher udev link priority on the multipath device, so when both the multipath device and its underlying paths request the same wwn- symlink, the multipath device wins.

MD RAID identifiers are stored in the array metadata and are always available. MD supports different metadata versions (0.90, 1.0, 1.1, 1.2) which store metadata in different locations, but identifiers are present regardless of version.

The MD UUID uses the format xxxxxxxx:xxxxxxxx:xxxxxxxx:xxxxxxxx (four groups of 8 hex digits separated by colons), which is specific to MD and not an RFC 4122 UUID. The MD name is only available with metadata version 1.x and is typically <hostname>:<array_number> (e.g., server1:0) for arrays created with mdadm, or a plain name. The older 0.90 metadata format does not have a name field.

To inspect an assembled MD array, use mdadm --detail. To examine the metadata on an underlying member device, use mdadm --examine.

Symlinks created by udev:

For example: