Label vs UUID vs Device

Someone asked on a mailing list about the issues related to whether to use a label, UUID, or device name for /etc/fstab.

The first thing to consider is where the names come from. The UUID is assigned automatically by mkfs or mkswap, so you have to discover it after the filesystem or swap space has been made (or note it during the mkfs/mkswap process). For the ext2/3 filesystems the command “tune2fs -l DEVICE” will display the UUID and label (strangely mke2fs uses the term “label” while the output of tune2fs uses the term “volume name“). For a swap space I don’t know of any tool that can extract the UUID and name. On Debian (Etch and Unstable) the file command does not display the UUID for swap spaces or ext2/3 filesystems and does not display the label for ext2/3 filesystems. After I complete this blog post I will file a bug report.

If you are using a version of Debian earlier than Lenny (or a version of Unstable with this bug fixed) then you will be able to easily determine the label and UUID of a filesystem or swap space. Other than that the inconvenience of determining the UUID and label will be a reason for not using them in /etc/fstab (keep in mind that sys-admin work sometimes needs to be done at 3AM).

One problem with mounting by UUID or label is that it doesn’t work well with snapshots and block device backups. If you have a live filesystem on /dev/sdc and an image from a backup on /dev/sdd then there is a lot of potential for excitement when mounting by UUID or label. Snapshots can be made by a volume manager (such as LVM), a SAN, or an iSCSI server.

Another problem is that if a file-based backup is made (IE tar or cpio) then you lose the UUID and label. tune2fs allows setting the UUID, but that seems like a potential recipe for disaster. So this means that if mounting by UUID then you would potentially need to change /etc/fstab after doing a full filesystem restore from a file-based backup, this is not impossible but might not be what you desire. Setting the label is not difficult, but it may be inconvenient.

When using old-style IDE disks the device names were of the form /dev/hda for the first disk on the first controller (cable) and /dev/hdd for the second disk on the second controller. This was quite unambiguous, adding an extra disk was never going to change the naming.

With SCSI disks the naming issue has always been more complex, and which device gets the name /dev/sda was determined by the order in which the SCSI HAs were discovered. So if a SCSI HA which had no disks attached suddenly had a disk installed then the naming of all the other disks would change on the next boot! To make things more exciting Fedora 9 is using the same naming scheme for IDE devices as for SCSI devices, I expect that other distributions will follow soon and then even with IDE disks permanent names will not be available.

In this situation the use of UUIDs or LABELS is required for the use of partitions. However a common trend is towards using LVM for all storage, in this case LVM manages labels and UUIDs internally (with some excitement if you do a block device backup of an LVM PV). So LV names such as /dev/vg0/root then become persistent and there is no need for mounting via UUID or label.

The most difficult problem then becomes the situation where a FC SAN has the ability to create snapshots and make them visible to the same machine. UUID or label based mounting won’t work unless you can change them when creating the snapshot (which is not impossible but is rather difficult when you use a Windows GUI to create snapshots on a FC SAN for use by Linux systems). I have had some interesting challenges with this in the past when using a FC based SAN with Linux blade servers, and I never devised a good solution.

When using iSCSI I expect that it would be possible to force an association between SCSI disk naming and names on the server, but I’ve never had time to test it out.

Update: I have submitted Debian bug #489865 with a suggested change to the magic database.

Below are /etc/magic entries for displaying the UUID and label on swap spaces and ext2/3 filesystems:

The following magic entry will display the UUID of a swap space as well as displaying the label in the same manner as the mkswap program:
# according to man page of mkswap (8) March 1999
# volume label and UUID Russell Coker
# http://etbe.coker.com.au/2008/07/08/label-vs-uuid-vs-device/
4086 string SWAPSPACE2 Linux/i386 swap file (new style),
>0x400 long x version %d (4K pages),
>0x404 long x size %d pages,
>1052 string \0 no label,
>1052 string >\0 LABEL=%s,
>0x40c belong x UUID=%x
>0x410 beshort x \b-%x
>0x412 beshort x \b-%x
>0x414 beshort x \b-%x
>0x416 belong x \b-%x
>0x41a beshort x \b%x

The following magic entry will display the UUID and label (AKA volume name) of an ext2/3/4 filesystem:
# ext2/ext3 filesystems – Andreas Dilger <adilger@dilger.ca>
# ext4 filesystem – Eric Sandeen <sandeen@sandeen.net>
# volume label and UUID Russell Coker
# http://etbe.coker.com.au/2008/07/08/label-vs-uuid-vs-device/
0x438 leshort 0xEF53 Linux
>0x44c lelong x rev %d
>0x43e leshort x \b.%d
# No journal? ext2
>0x45c lelong ^0x0000004 ext2 filesystem data
>>0x43a leshort ^0x0000001 (mounted or unclean)
# Has a journal? ext3 or ext4
>0x45c lelong &0x0000004
# and small INCOMPAT?
>>0x460 lelong <0x0000040
# and small RO_COMPAT?
>>>0x464 lelong <0x0000008 ext3 filesystem data
# else large RO_COMPAT?
>>>0x464 lelong >0x0000007 ext4 filesystem data
# else large INCOMPAT?
>>0x460 lelong >0x000003f ext4 filesystem data
>0x468 belong x \b, UUID=%x
>0x46c beshort x \b-%x
>0x46e beshort x \b-%x
>0x470 beshort x \b-%x
>0x472 belong x \b-%x
>0x476 beshort x \b%x
>0x478 string >0 \b, volume name "%s"
# General flags for any ext* fs
>0x460 lelong &0x0000004 (needs journal recovery)
>0x43a leshort &0x0000002 (errors)
# INCOMPAT flags
>0x460 lelong &0x0000001 (compressed)
#>0x460 lelong &0x0000002 (filetype)
#>0x460 lelong &0x0000010 (meta bg)
>0x460 lelong &0x0000040 (extents)
>0x460 lelong &0x0000080 (64bit)
#>0x460 lelong &0x0000100 (mmp)
#>0x460 lelong &0x0000200 (flex bg)
# RO_INCOMPAT flags
#>0x464 lelong &0x0000001 (sparse super)
>0x464 lelong &0x0000002 (large files)
>0x464 lelong &0x0000008 (huge files)
#>0x464 lelong &0x0000010 (gdt checksum)
#>0x464 lelong &0x0000020 (many subdirs)
#>0x463 lelong &0x0000040 (extra isize)