[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: UUID - autmatically entries?



In <[🔎] 20110522045227.GD11987@cmpq.lan.gnu>, Paul E Condon wrote:
>On 20110522_035930, annathemermaid@hush.com wrote:
>> I used devices, just like I always do when editing
>> fstabs. It works fine. I don't see any reason to change it? What do
>> UUIDs give me that /dev/hdx or /dev/sdx don't, aside from being
>> harder to read and a pain to setup?
>
>As I understand it, there can be a problem if you add or remove
>peripheral internal hardware, i.e. add or remove a single hard disk on
>a system that has half a dozen hard disks , can result in *all* the
>hard disks getting different device names assigned on the next boot and
>stay that way until corrective action is taken manually.

Two (quick?) examples:

1. Your main drive normally shows up as /dev/sda.  You plug in a USB key after 
booting and it shows up as /dev/sdb.  During an abnormal event, the system is 
rebooted with the USB key in place.  The system won't reboot by itself because 
the USB key is now assigned the name /dev/sda and the main drive is /dev/sdb.  
This can happen for multiple reasons, all having to do with the hardware 
(combinations).  This can (and did) happen with static /dev, devfs, and udev.  
The can (and did) happen both with the old serial kernel hardware probing and 
with the new parallel asynchronous kernel hardware probing.

2. You have an HBA that connects to some storage (internal or external) and 
exposes volumes as SCSI disks.  You have disks on SCSI chain 0 (/dev/sd[ab]) 
and SCSI chain 1 (/dev/sd[c-g]).  During some storage management, you run into 
some limitations of the HBA and, as a work-around, remove all the volumes on 
SCSI chain 0 (/dev/sd[ab] become inaccessible) and create larger volumes on 
SCSI chain 2 (/dev/sd[hi]).  Upon the next boot, all the accessible devices 
change names.  Again, this issue existed even before udev or the new kernel 
probing method.

Using labels or UUIDs in /etc/fstab avoids or minimizes the impact of both 
these scenarios.  Also, udev and/or the /dev/disk/by-* files can avoid or 
minimize the impact of both these scenarios.

In addition, the parallel asynchronous kernel probing create(d/s) additional 
issues, where devices might change names from boot to boot even without any 
"hardware" changes (some might say both my examples as hardware changes), due 
to timing issues that vary from boot to boot or are different when "cold" 
booting vs. when "warm" booting.

I (and the Squeeze release notes) recommend using labels or UUIDs whenever 
possible to simply avoid the issue.  If you feel like depending on udev, the 
/dev/disk/by-* names should work as well.  (LABEL= and UUID= syntaxes are not 
dependent on udev, only on a "recent" util-linux, IIRC.)
-- 
Boyd Stephen Smith Jr.                   ,= ,-_-. =.
bss@iguanasuicide.net                   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy         `-'(. .)`-'
http://iguanasuicide.net/                    \_/

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: