[prev in list] [next in list] [prev in thread] [next in thread]
List: debian-user
Subject: Re: UUID - autmatically entries?
From: "Boyd Stephen Smith Jr." <bss () iguanasuicide ! net>
Date: 2011-05-22 7:34:50
Message-ID: 201105220234.55764.bss () iguanasuicide ! net
[Download RAW message or body]
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/ \_/
["signature.asc" (application/pgp-signature)]
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/201105220234.55764.bss@iguanasuicide.net
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic