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

Robert Pearson e2eiod at gmail.com
Tue Jun 17 01:56:58 CDT 2008


On Mon, Jun 16, 2008 at 9:31 PM, Daniel J. Givens <daniel at rugmonster.org> wrote:
> 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
> --

Thanks, Daniel. This info is great!
Just what I have been needing.

Robert


More information about the SATLUG mailing list