[SATLUG] Drive ID Change (sdx vs hdx) -or- Why UUIDs Rock!

Daniel J. Givens daniel at rugmonster.org
Mon Jun 16 21:31:39 CDT 2008


On Mon, 16 Jun 2008 19:55:18 -0400
"scs at worldlinkisp.com" <scs at worldlinkisp.com> wrote:

> >------- Original Message -------
> >Geoff wrote:
> >I'm thinking it's a kernel thing.  SuSE 10.3 also
> re-defines /dev/hd* now as /dev/sd*
> ------------------------------------
> 
> This drive ID change to sd_ from hd_ has been around
> for a year or more in kernel 2.6.___ 

That's why you may or may not have noticed some distros moving to UUIDs (or 
Universally Unique Identifiers) in /etc/fstab. It's a means by which you can 
refer to a particular filesystem or block device independently of the kernel 
assigned device name. 

I'll use my box at home for example purposes. I've got three separate SATA 
controllers and a total of 8 drives. This has been especially useful for me 
because 2 of those drives are external, connected via eSATA. The /dev/sd* varies
between reboots for the 2 external drives and the 4 internal that make up a 
raid5 volume. To make things more complicated, the raid volume that the 2 
externals make up has a single ext3 partition. The raid5 volume is set up with 
LVM and a couple logical volumes. Rather than try to reference all of these 
different /dev entries in my fstab, I simply reference the UUID of each 
filesystem and let the system sort it out.

My /etc/fstab:
# Device ID                               Mount Point  FSType Options
# ======================================= ============ ====== ================================================  
UUID=f352e4de-6c46-4d20-8c03-4c4596521fa4 /            ext3   defaults,acl,user_xattr                          1 1
UUID=ad91af6d-9206-4f0c-b5b3-e308169d3d3f /boot        ext3   defaults                                         1 2
UUID=e89e0989-1668-4e07-8d21-c0d095dd0991 /mnt/backup  ext3   defaults,nodev,acl,user_xattr                    1 2
UUID=d14713b8-dac0-45d5-a3c9-e132e339f36e /mnt/storage ext3   defaults,nodev,noatime,nodiratime,acl,user_xattr 1 2
UUID=55918092-a896-4586-bfdc-a7d92579d275 swap         swap   defaults                                         0 0
UUID=06c8c6f6-c302-446b-b18b-ea1ff94d2d7e swap         swap   defaults                                         0 0
tmpfs                                     /dev/shm     tmpfs  defaults                                         0 0
devpts                                    /dev/pts     devpts gid=5,mode=620                                   0 0
sysfs                                     /sys         sysfs  defaults                                         0 0
proc                                      /proc        proc   defaults                                         0 0

The actual mapping for those UUIDs goes like this.


06c8c6f6-c302-446b-b18b-ea1ff94d2d7e -> /dev/sda5
55918092-a896-4586-bfdc-a7d92579d275 -> /dev/sdb5
ad91af6d-9206-4f0c-b5b3-e308169d3d3f -> /dev/md0
e89e0989-1668-4e07-8d21-c0d095dd0991 -> /dev/md2
f352e4de-6c46-4d20-8c03-4c4596521fa4 -> /dev/mapper/VGSys-LVroot
d14713b8-dac0-45d5-a3c9-e132e339f36e -> /dev/mapper/system-storage

Notice I've used the UUID even for the LVM logical volumes. Considering these
are mapped at boot, I can likely trust that they won't change unless someone
decides they want to change the standard convention of mapping such things.
Hmmm... that sounds like something very familiar...

To find the UUID of a filesystem, you can use 'blkid'. Here's a sample of its
usage:

# blkid /dev/sda5
/dev/sda5: TYPE="swap" LABEL="SWAP-sdb5" UUID="06c8c6f6-c302-446b-b18b-ea1ff94d2d7e"

You have to run the command as a user with read access to the block device you
are querying. 

$ ls -l /dev/sda5
brw-r----- 1 root disk 8, 5 2008-06-15 17:25 /dev/sda5

On my system, my account would need to be a member of the disk group, or I could
run it as root.

You might also notice from the output of blkid, when I first setup that volume,
it was apparently /dev/sdb5 at the time. I have since reordered my drives in
relation to the ports on the sata controllers. I never noticed until just now.

Not only is using UUIDs useful in /etc/fstab, in the grub config, you can pass a
UUID to the kernel to specify the root partition. I had an instance sometime 
last year following a kernel upgrade on a server where it simply wouldn't boot 
because the menu.lst referred to /dev/hda1, but that device no longer existed in
the eyes of the new kernel. Unfortunately, I was not aware of the changing 
convention and made a 2 hour trip to get the box booted. It really confused the 
local folks because they were afraid the box was trying to boot off of one of 
the two drives in a mdadm raid1 pair. They refused to touch the thing for fear 
of corrupting the raid set. (They didn't realize the Dell PowerEdge 2850 has a 
hardware sata raid controller onboard)

And the last instance I'll mention is for the software raid folks. In 
/etc/mdadm.conf, you can specify the UUID for the raid set rather than the
individual devices that make it up. 

My /etc/mdadm.conf:
DEVICE partitions
MAILADDR root

ARRAY /dev/md1 level=raid1 num-devices=2 UUID=998eeaaa:e4102d4b:af2427ad:b5a4edee
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=92f80d3e:4f37b0bb:6a7cd125:b14901ad
ARRAY /dev/md2 level=raid0 num-devices=2 UUID=f9a8d82d:a53a3889:c852260f:ef00f11a
ARRAY /dev/md3 level=raid5 num-devices=4 UUID=66704043:fd5456c6:fb8d2c92:670c5552

With this config, I can reorder my drives all day long and not worry about my
raid devices changing names. Since mdadm.conf isn't required in most instances,
it isn't such a big deal, but it's helpful if you want to ensure all of your
settings get applied on system boot. And to me, this is a lot easier to deal 
with compared to listing out each individual device.

It's important to keep in mind that the UUID for a raid set is completely 
separate from the UUID of any filesystems it may contain. To find out the UUID
for an mdadm raid volume, you use the --detail option for mdadm:

# mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90.03
  Creation Time : Thu May  8 00:49:50 2008
     Raid Level : raid1
     Array Size : 497856 (486.27 MiB 509.80 MB)
  Used Dev Size : 497856 (486.27 MiB 509.80 MB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Sun Jun 15 17:26:14 2008
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : 92f80d3e:4f37b0bb:6a7cd125:b14901ad
         Events : 0.4

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       8        1        1      active sync   /dev/sda1

You can also get the UUID for a raid set that hasn't been assembled yet by 
examining one of the component devices.

# mdadm --examine /dev/sda1
/dev/sda1:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : 92f80d3e:4f37b0bb:6a7cd125:b14901ad
  Creation Time : Thu May  8 00:49:50 2008
     Raid Level : raid1
  Used Dev Size : 497856 (486.27 MiB 509.80 MB)
     Array Size : 497856 (486.27 MiB 509.80 MB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0

    Update Time : Mon Jun 16 21:08:30 2008
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0
       Checksum : 37a22a53 - correct
         Events : 0.4


      Number   Major   Minor   RaidDevice State
this     1       8        1        1      active sync   /dev/sda1

   0     0       8       17        0      active sync   /dev/sdb1
   1     1       8        1        1      active sync   /dev/sda1

If you compare the output of the --detail on md0 and --examine on sda1, you will
see that the UUIDs are the same. This can be extremely helpful should mdadm fail
to assemble your raid set on boot, as was the case with my 2 esata drives.

Things to keep in mind about UUIDs:

1. When you format a filesystem, the filesystem gets a new UUID
2. When you wipe the superblocks for all constituent devices in a mdadm raid
   set, your UUID is gone forever
3. With the exception of a few possible corner cases, a UUID should never change
   unless someone purposely changes it
4. You can generate a new UUID using the 'uuidgen' command (see man 1 uuidgen)

I mostly when off the cuff on this, so there may be some errors and/or 
omissions. Corrections are always invited. Once I got really into this, I
started thinking I may use this for the basis of an article on Linux storage 
and UUIDs.

Cheers,
Daniel


More information about the SATLUG mailing list