What is the reasoning behind using UUIDs in /etc/fstab instead of device names (like /dev/sbd2)?

Device names &/or partition numbers seem substantially cleaner from an administrative viewpoint.

  • 1
    I think this is useful to garantee device detection/activation in same order on each boot or detection process to avoid mounting /dev/sdXY different datas from 2 different boot.... I think there are better use of it :) ... or better reasons :) – francois P Feb 12 '18 at 20:40

Because device names aren't guaranteed to be the same across a reboot.

There are some systems out there where the order in which devices get enumerated is not constant across reboots (most often, this involves very big storage arrays or USB connected devices). On such a system, /dev/sda on one boot might end up being /dev/sdb on another boot, and /dev/sdz on a third boot. I used to have a ThinkPad laptop that would enumerate USB connected storage devices before the built-in SATA hard drive, so it would fail to boot if I used device names and plugged in a flash drive while powering the system on.

Aside from that though, you might do someihing inside the case, and plug the disk drives back in in the wrong order (most people don't physically label their drives).

In either case, you need to identify your devices in some other way. The obvious choice for this is to look at filesystem labels, but those have their own issues, most notably that they're easy to guess and therefore it's easy to cause issues with a system using them by simply plugging in a flash drive with a correctly guessed filesystem label.

As a result, UUID's are what has been standardized on, since they are hard to guess, and still provide the relative uniqueness that filesystem labels do.

Note that this is the same kind of problem that has resulted in a movement away from usage of the eth* and wlan* naming for network cards, as those names can change around depending on the order the cards are plugged in.

| improve this answer | |
  • 2
    +1. The drive detection order problem is more common than your answer implies, though. Many factors effect the order that drive interfaces and drives are detected in, including module load order, kernel version (i.e. upgrading the kernel can change the drive detection order), drive spin-up time, installing a new drive, or removing an old one, and more. Also, the kernel devs have repeatedly made the point that drive detection order is not guaranteed to be the same across reboots and can not ever be relied upon. – cas Feb 13 '18 at 0:18

Not the answer you're looking for? Browse other questions tagged or ask your own question.