Imagine a scenario in a data center where a reboot causes a critical database server to fail. Upon investigation, you discover that what was previously identified as /dev/sdb1 is now /dev/sdc1. The system, relying on volatile hardware paths, failed to mount the correct storage volume. This is the exact problem that Universally Unique Identifiers (UUIDs) were designed to solve.

In the Linux ecosystem, identifying a disk partition isn't as simple as checking a drive letter. There are two primary, yet distinct, identifiers that every system administrator and power user must understand: the Filesystem UUID and the Partition UUID (PARTUUID). While they look similar—long strings of hexadecimal characters—their roles, storage locations, and behaviors under system changes are fundamentally different.

The Volatility of Device Names

Traditional device naming, such as /dev/sda or /dev/nvme0n1, is a dynamic process handled by the kernel during boot. The kernel assigns these names based on the order in which devices are discovered by the hardware controller. If you add a new disk, move a cable to a different SATA port, or even experience a slight delay in a disk spinning up, the order can change.

Relying on /dev/sdX names in configuration files like /etc/fstab is a recipe for disaster. This is why modern Linux distributions have transitioned entirely to using UUIDs. A UUID is a 128-bit number used to identify information in computer systems. Because they are designed to be unique across time and space without a central authority, they provide a rock-solid method for disk identification.

The Filesystem UUID: Metadata Inside the Volume

The Filesystem UUID (often just referred to as "UUID") is a property of the filesystem itself (e.g., ext4, XFS, Btrfs, NTFS). It is generated at the moment you format a partition.

Where is it stored?

The Filesystem UUID is stored within the filesystem's metadata, specifically in the "superblock" for ext-family filesystems or equivalent structures in others. For example, in an ext4 filesystem, the struct ext2_super_block contains a field s_uuid[16] that holds these 128 bits.

When does it change?

The defining characteristic of a Filesystem UUID is that it is tied to the data structure of the volume.

  • If you reformat the partition (e.g., changing from ext4 to XFS), the UUID will change because a new filesystem with a new metadata block is created.
  • If you resize the partition without reformatting, the UUID typically remains the same.
  • If you clone a partition using a block-level tool like dd, the UUID is copied exactly, which can lead to "UUID collisions" where the system sees two different disks with the same ID.

Primary Use Case

The Filesystem UUID is the standard for mounting volumes. When you see a line in /etc/fstab that starts with UUID=550e8400-e29b-41d4-a716-446655440000, the system scans all available block devices, reads their filesystem headers, and mounts the one that matches.

The Partition UUID (PARTUUID): The GPT Identity

The Partition UUID (PARTUUID) is a different beast entirely. It does not care about the data inside the partition. Instead, it is a feature of the Partition Table itself.

The Role of GPT

PARTUUIDs are a core component of the GUID Partition Table (GPT) scheme, which replaced the legacy Master Boot Record (MBR). In a GPT disk layout, each partition entry in the partition table is assigned a "Unique Partition GUID."

Where is it stored?

According to the UEFI Specification (e.g., version 2.10), the PARTUUID is stored in the Partition Entry Array, which typically starts at Logical Block Address (LBA) 2 on the disk. Each partition entry is 128 bytes (or more), and the offset 16 to 31 within that entry contains the 16-byte Unique Partition GUID.

When does it change?

The PARTUUID is tied to the "slot" in the partition table.

  • Reformatting the filesystem does not change the PARTUUID because the partition table remains untouched.
  • Deleting and recreating a partition (even with the same start/end sectors) will usually result in a new PARTUUID, as most partitioning tools (like gdisk or fdisk) generate a new GUID by default.
  • Wiping the filesystem metadata has no effect on the PARTUUID.

Primary Use Case

PARTUUIDs are critical in scenarios where a filesystem might not yet exist or might be unrecognizable by the bootloader. They are frequently used in kernel boot parameters (e.g., root=PARTUUID=...) to tell the kernel which physical partition contains the root filesystem, especially in embedded systems or when using complex storage stacks where the filesystem UUID might be obscured.

Technical Comparison: UUID vs. PARTUUID

Feature Filesystem UUID Partition UUID (PARTUUID)
Storage Location Filesystem Superblock (Inside the partition) GPT Partition Table (Outside the partition)
Creation Event mkfs (Formatting) Partition creation (e.g., gdisk)
Scope Tied to the filesystem and data Tied to the partition entry and layout
Persistence Survives partition resizing Survives filesystem reformatting
Legacy MBR Support Yes (stored in FS metadata) Limited (emulated via Disk Signature)
Fstab Usage Preferred for mounting Backup/Advanced identification

How to Find Partition Identifiers in Linux

In our testing, we found that using a combination of commands provides the most comprehensive view of your disk's identity. Here is how to retrieve these identifiers efficiently.

1. Using lsblk for a Tree View

The lsblk command is the cleanest way to see the relationship between physical disks and their IDs.