Why does fstab use UUID instead of the actual file system name?

Question

For example, this is the first line of my /etc/fstab:

UUID=050e1e34-39e6-4072-a03e-ae0bf90ba13a    /    ext4    errors=remount-ro    0    1

And here's the output of df -h command (reporting free disk space):

honey@bunny:~$ df -T

Filesystem     Type     1K-blocks    Used Available Use% Mounted on
/dev/vda       ext4      30832636 4884200  24359188  17% /
none           tmpfs            4       0         4   0% /sys/fs/cgroup
udev           devtmpfs    498172      12    498160   1% /dev
tmpfs          tmpfs       101796     320    101476   1% /run
none           tmpfs         5120       0      5120   0% /run/lock
none           tmpfs       508972       0    508972   0% /run/shm
none           tmpfs       102400       0    102400   0% /run/user

1. From the two is it okay to deduce that UUID=050e1e34-39e6-4072-a03e-ae0bf90ba13a represents /dev/vda given that the first column in fstab is <file system>?

2. So, would it be okay if I modified /etc/fstab to this?

   /dev/vda    /    ext4    errors=remount-ro    0    1
   

3. EDIT: If yes (to above question), why does the sudo blkid command show a different UUID for /dev/vda?

   $ sudo blkid
   
   /dev/vda: LABEL="DOROOT" UUID="6f469437-4935-44c5-8ac6-53eb54a9af26" TYPE="ext4"
   

   What am I missing here?

   Answer: I'd conclude (3) to be a bug in the cloud of my host. So yes, the UUID reported by blkid (or ls -l /dev/disk/by-uuid) should be the same as the one used in /etc/fstab.

Answer 1

The advantage of using the UUID is that it is independent from the actual device number the operating system gives your hard disk.

Imagine you add another hard disk to the system, and for some reason the OS decides that your old disk is now sdb instead of sda.

Your boot process would be screwed up if fstab points to the device name. But in case of the UUIDs, it is fine.

More detailed information about UUIDs can also be found on the blog post "UUIDs and Linux: Everything you ever need to know"

Answer 2

In that case, can I modify /etc/fstab to this?

You can and it will probably be okay, but most likely it would be better to leave the UUID.

UUIDs are arbitrary strings used to identify, in this case, a partition on a block device; its stored with the partition itself, and can be assigned a different one if desired (sort of like MAC addresses).

The advantage of using the UUID is that it is unmistakable, whereas /dev/vda is not; it could happen that it ends up being a different drive at boot time, although this may be totally theoretical in context (e.g., because you only have one drive of a particular type).

Another more subtle example of where using the device name can cause a problem would be the recent switch on some systems to using consistent network device names. If this occurred as an upgrade and you used a hardcoded device name in a network script somewhere, it would break. A parallel example WRT block devices might be a kernel or udev upgrade which changes the naming scheme.

One point of UUIDs is to make these kind of things possible and painless. So while you can use the device name, there is no advantage to doing so unless (e.g.) you have a system where you swap different drives in. In other words, if you don't have a good reason to do that, stick with the UUID.

Answer 3

You can do man fstab for a fairly concise read on the contents and semantics of the /etc/fstab file. On my x86, fairly up-to-date Arch linux server, man fstab gives me this:

The second field ... describes  the mount point for the filesystem.

So, yes, /dev/vda apparently is one of many names for some device, as is UUID=050e1e34-39e6-4072-a03e-ae0bf90ba13a, given that both names appear to mount on "/".

If you look in the directory /dev/disk/by-uuid/ you can see symbolic links that point to things like /dev/sda1, /dev/sdb1 on my server. This might be another way to check your hypothesis. /dev/disk has subdirectories by-id, by-path, by-uuid which all appear to be alternate names for the same device.