If you’ve been using Linux for a bit you will be familiar with the file systems table (fstab(5): /etc/fstab). You will also be fairly familiar with the contents of this file and it’s structure:
<device> <mount-point> <filesystem-type> <options> <dump> <pass>
So a typical entry may possibly look like the following:
/dev/sda1 / ext4 defaults 0 0
This would mount /dev/sda1, the device file for the first partition on the first disk as the root (/) on your Linux system.
Now you have possibly seen a problem… this device might change names and no longer be /dev/sda1 next boot. Imagine performing an install from a live CD, the mappings of devices might change between booting the live CD and booting from the hard disk.
If you looked at your actual fstab, you will notice that instead of devices being identified by /dev/sdx, you will see the use of UUIDs. This method is considered the safest and most reliable way of mounting a plain old block device.
To find a UUID, simply run the blkid command.
# blkid /dev/sda1
/dev/sda1 UUID="15983cac-77bc-46b1-9f79-cb180e438a64" TYPE="ext4"
Your fstab now looks more like this, using UUID to identify the filesystem we wish to mount:
UUID=15983cac-77bc-46b1-9f79-cb180e438a64 / ext4 defaults 0 0
LVM
Let’s think about an example logical volume, 10 GB spread across a 16 GB volume group composed of two 8 GB disks:
Now there is the temptation to put the UUID entry into your fstab.
# lsblk -f
Using this UUID in your fstab, you will be able to mount the filesystem consistently, surely? It’s the best practice for mounting any other volume:
UUID=cefcdc28-ac6b-4a26-a14e-e27724489c52 /backup ext4 defaults 0 0
Alas, no.
Why?.. Snapshots. This problem also applies for filesystems that support snapshots such as zfs.
I’ll demonstrate now by creating a snapshot of my logical volume and then re-run the command for finding the UUID.
As you may have noticed, the original volume and the snapshot have exactly the same UUID. If I add this UUID to my fstab now, umount and mount; the snapshot volume will mount to /backup. This is potentially not the behavior we want.
So what do we do? What goes into our fstab? Let’s look at the options available to us on this openSUSE VM. We have:
/dev/mapper/vg_test-lv_test/dev/vg_test/lv_test/dev/dm-#
On more modern Linux OS, the top 2 options are the same, a symlink to the device file /dev/dm-# (/dev/dm-1 in my example).
We shouldn’t reference /dev/dm-1 in our fstab though as this reference is not persistent on reboot. We cam also have an increase or decrease in the number of device-mapper device files when we make snapshots. Additionally volumes will likely move around when re-discovered by device-mapper on boot.
So what the heck do we use? Despite going against what was previously said in the introduction, either:
/dev/mapper/vg_test-lv_testor/dev/vg_test/lv_test
Preferably /dev/mapper/vg_test-lv_test as this used to be where device-mapper originally created the device file, (instead of /dev/dm-#).
I would also recommend using the /dev/mapper/vg_test-lv_test because I have also had experiences of the /dev/vg_test/lv_test symlink going missing during a reboot and requiring emergency console access.
On older systems, /dev/mapper/vg_test-lv_test is more likely to be persistent than /dev/vg_test/lv_test.
Conclusion
When adding a device to fstab, unless you are using LVM or a filesystem that supports snapshots*, use the UUID.
When using LVM, use the /dev/mapper/vg_volgrp-lv_logvol device file (or symlink for later Linux OS).
*btrfs users, carry on using UUID but specify the subvolume name.