[Novalug] Device naming
waltechmail at yahoo.com
Thu Mar 11 14:53:46 EST 2010
For Alan, I hear your frustration. And I think your
query is a good one. Both from the POV of asking "why did
it change", and "how does the present system work".
>From my selective memory, I remember two ongoing lines of conversation
regarding dynamic assignment. I'm sure I'll be corrected or
There was a large problem with name conflicts from various vendors
of drivers. They each tried claiming a particular "name" for
their devices. And naturally, some wanted the same name !!
There was also the problem of the large number of files
in the /dev directory. In fact, it was obvious many more thousands
of device names was possible for some systems.
So something needed to be done. And others had already had
implemented their own solutions (I didn't keep track of who/what).
I think the point about how to know what device names you have
is a good one. Bryan makes the significant point you don't use
a name anymore: use a UUID.
OK: except my gnome network gui sometimes assigns a
default name for something or other.... sometimes modem, sometimes
it might be a tty. I do a
and get /dev/stuff !!
So a sys admin needs to know ( and users often too !! )
what is going on. Some sys admins work is at a different level
than others. So some might need cursory info and others indepth.
Same for the device drivers- especially if you have two to choose from
where one or both are not open source. Look at the continuing NVidia
I still plug in a hard disk and do a manual mount using /dev/sd-!!
every once in awhile. An example using a UUID would be
Now, I didn't learn implementation details. I'm curious-
but not interested in writing device drivers.
So I would also be interested in how the UUID ( what is it )
and how is it used. Or point me to a specific link.
Contrast to dev name such as /dev/sda. Note that the /dev dir
is chock FULL of device names !! so there MUST be a reason to
have them? I don't see a dir full of UUID's !! ( I'm just
gooseing a little for a nice explanation). And how does this
work for hotpluggin' ( for cmhowes benefit) ?? His fd ( flash drive)
gets a name and he doesn't have to "mount it". Again, an overview
( or good link ) to how this mechanism works would be useful.
I also note that all of these system resource mechanisms are a lot
more complicated than they used to be, making them a convenience to
the user ( this was mentioned or alluded to in previous "Device"
Also, lets not forget there is a SCSI software protocol
of sorts in addition to real SCSI hardware. Are there other
"SCSI" thingys?? Inquiring minds want to know !
I always appreciate SOME information, including a hint, or light
overview or even a keyword as assistance if that is the extend
of the submitters experience..
For others, I would suggest the list here could be used more to
help rather than mention some buzzword and say "go read it" using
A google search followed by 3 hours of reading crap before finding
the right article.
Hell, I could always do that without being on this list.
A decent link is always good.
Thanks for any enlightenment.
>Short answer ...
>Hit any of the countless udev howtos on how to lock down devices
>to specific device names, with specific permissions, etc...
>Otherwise, just rely on the UUIDs of the filesystems, and ignore the
>Long answer ...
>First off, reassignment of devices happens in _all_ OSes.
>This is hardly a Linux phenomenon. I have no idea what
>your intent is here (other than what I shall not say).
>Secondly, because reassignment is such an issue, Fedora,
>Ubuntu and countless other distros have switched to UUIDs
>for filesystem identification. UUIDs are unique. This also
>caused a lot of blame and demonizations when people
>started seeing UUIDs in /etc/fstab as well, without stopping to
>understand why this very necessary decision was finally made.
>Third, the udev system allows one to tie down device names
>to specific hardware using hardware IDs and other details.
>Indeed, this is how I often deal with SAN and other devices.
>It's also where multipathing ties into as well. And at home,
>I also use udev rules to assign devices for my removable
>USB devices. If you absolutely want to ensure specific naming,
>permissions, etc... with a device, use udev. If you don't need to,
>then just rely on UUIDs.
>Fourth, the decision was made long ago to unify most read/
>write block device names as "sdX" devices and most read-only
>block devices as "sr0" devices. The "SCSI" name is largely
>a left-over. There are countless devices that use the SCSI
>block system that do _not_ support SCSI protocols at all --
>FireWire, USB, etc... So don't assign any attachment to the term
>"SCSI." It also unified the labeling/ID as well, making things far,
>far more consistent than prior. Other OSes do this as well (NT
>comes to mind too, along with several UNIX flavors). SCSI is
>just a read/write block interface, whether dumb block or one
>with a more intelligent command-set like SCSI-2, FireWire, etc...
>Lastly, the "old schemes" are fine when you have limited device
>support. But today, modern Linux has countless support of an
>extremely broad range of devices. The "old schemes" don't fit
>well, let alone are grossly inconsistent. The "new schemes" are
>much better, avoid device issues and other details. I wouldn't
>say this if I have not run into assignment and other details under
>all OSes. Newer approaches in Linux 2.6-based distro do a
>far better job now.
>One either chooses to move forward or one only exposes that
>they have not -- let alone has not taking the time why the changes
>were made and should move forward. ;)
>----- Original Message ----
>From: Alan Grimes <agrimes at speakeasy.net>
>To: linux-hotplug at vger.kernel.org; Northern Virginia Linux User's Group <novalug at calypso.tux.org>
>Cc: Scott D'Vileskis <sdvileskis at chemgen.com>
>Sent: Thu, March 11, 2010 10:37:13 AM
>Subject: [Novalug] Device naming.
>Due to the lack of documentation on the subject, I have been forced to
>do my own investigation and make my own conclusions regarding recent
>changes to the naming of devices on linux.
>My verdict is that it's the latest example in a chain of spectacularly
>bad design decisions made by linux developers (Penguins) in the past
>year or two.
>The purpose of the /dev path is to allow administrators to access
>devices attached to their systems. Therefore it is sensible for each
>device handle to expose to the administrator essential facts such as
>what type of device it is, which controller it is attached to, the
>position number on that controller and, finally, the identifier of any
>virtual devices which might benefit from being treated separately.
>Furthermore the administrator doesn't have the slightest interest in
>what driver is behind the device, that is irrelevant information that
>should be hidden.
>Minix, IIRC did this correctly. Each name has a very easy to understand
>The old scheme on Linux did an adequate job of this too. The first two
>letters indicated what technology it was, the third letter was a mix of
>controller and position information, and the number indicated the
>virtual device being referenced.
>I did an experiment the other day which involved plugging a USB thumb
>drive into the server. To my horror, the operating system assigned it
>/dev/sda. The Penguins had gone and *intentionally* designed a namespace
>collision between all possible storage solutions that might be attached
>to the computer!!!
>This is insane. How do I know what drives are which when I go to write
>an /etc/fstab? If I make any changes to the controllers in the system,
>designations of existing drives are sure to change. =\
>I am aware of /dev/disk so don't flame me about THAT, I have examined it
>closely and have not found any way to make use of it because it is not
>possible to reliably predict how a new drive would appear there.
>On my existing system that is still running an old linux kernel, the
>device ID of my boot drive is:
>Which is correct...
>But the device id of my data drive is:
>Which is wrong because I don't own any SCSI hardware. It should be:
>WTF??? My data drive has two entries in there, the other is:
>Which is not that inaccurate because SATA is a form of ATA, however it
>is useful to be able to distinguish the two so you know where your new
>drive will appear.
More information about the Novalug