[Novalug] Device naming

Thu Mar 11 16:47:48 EST 2010

On Thu, 2010-03-11 at 11:53 -0800, Walt Smith wrote:
> Hi List,
> 
> 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".

Well, Alan's post wasn't a "query" but a statement. And a wrong one in
addition.

> 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.

The hot-plugable development was the primary driver of udev. Things are
not working as they used to. A computer has devices added and removed
while running today. In the olden days, that was a biiiig no-no, so we
could keep things static. Another quick note - linux/unix doesn't really
care about the device "name" - it cares about two little numbers: major
and minor. You can create any block device name and point them to the
same numbers, and you'll get nicely access to the same device. This is
another area where linux was running out of option. These numbers are
unsigned bytes. That limits your support of a lot of hardware. We needed
a different way of accessing devices - so udev was followed sysfs.

> So something needed to be done. And others had already had
> implemented their own solutions (I didn't keep track of who/what).

Indeed ... 

> 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 
> $mount
> and get /dev/stuff !!

This is how most users will operate; it's partly due to fuser and a gfs.
If a label is found on the device you attach, the name comes from that -
otherwise you can get some funky names/numbers auto-generated. But to
most end-users, as long as you can see the device you added on your
desktop, they're happy campers. It's as easy as it gets. It even tries
to resolve busy conflicts when you umount things - no more "cannot eject
cd" because my PWD happens to be in /mnt/cdrom.

> 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
> problem.

This is another reason for gfs, sysfs and udev. While complex to
implement, they're a lot easier to "manage". You definitely don't need
to know how to create a driver to use the device. But some knowledge
will take you long way on how to do things "right" and avoid problems.

> 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 
> helpful.

$ mount UUID=xxxxx /mnt/mountpoint

This is from my /etc/fstab:
UUID=3246c760-03c4-46bf-9d67-c9aea9b68318 /boot                   ext3
defaults        1 2

In this case, the UUID is defined by ext3.

> 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.  

Well, first "man uuidgen" - generating uuid's is rather simple. The
number/string is so long that it's going to be "when hell freezes over"
before you get a duplicate.

UUIDs are a simple identifier. It's used by a lot of tools and in
software development. Even Windows makes good use of them to keep things
separate between vendors. When it comes to devices, there are devices
where hardware firmware has a UUID, but in most cases you'll find it in
the device mapper and the file system. When your system scans the
partitions I'll read the UUIDs from DM and the file systems it founds in
the partition scan.  They're no secret - to see what UUIDs have been
found simply:

$ ls /dev/disk/by-uuid/
116904a2-ea28-43aa-bcad-3bdbeb960f86  
5abcdd78-2fa5-4f95-93e5-1a7d22fc02d7
2d6425a9-995b-4f88-9dde-8bcccf3dfd3d  
6334-3231
3246c760-03c4-46bf-9d67-c9aea9b68318  
65f37657-ec65-468f-9e41-e6fee6f06ccb
38562174562133D2                      
e8492838-1764-4719-915f-d143213e64b6

Even better - those are symbolic links, so to see what they present, do:
$ ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx. 1 root root 10 2010-03-11 05:11
116904a2-ea28-43aa-bcad-3bdbeb960f86 -> ../../sdb2
lrwxrwxrwx. 1 root root 10 2010-03-11 05:11
2d6425a9-995b-4f88-9dde-8bcccf3dfd3d -> ../../dm-1
lrwxrwxrwx. 1 root root 10 2010-03-11 05:11
3246c760-03c4-46bf-9d67-c9aea9b68318 -> ../../sda2
lrwxrwxrwx. 1 root root 10 2010-03-11 05:11 38562174562133D2
-> ../../sda3
lrwxrwxrwx. 1 root root 10 2010-03-11 05:11
5abcdd78-2fa5-4f95-93e5-1a7d22fc02d7 -> ../../dm-0
lrwxrwxrwx. 1 root root 15 2010-03-11 10:20 6334-3231 -> ../../mmcblk0p1
lrwxrwxrwx. 1 root root 10 2010-03-11 05:11
65f37657-ec65-468f-9e41-e6fee6f06ccb -> ../../dm-3
lrwxrwxrwx. 1 root root 10 2010-03-11 05:11
e8492838-1764-4719-915f-d143213e64b6 -> ../../dm-2

(sorry - lines are too long to fit here - each UUID and map should be on
a single line).

Lastly, if you are REALLY in doubt what device a UUID points to, you can
use findfs:

$ findfs UUID=3246c760-03c4-46bf-9d67-c9aea9b68318
/dev/sda2

(findfs works with labels too).

If you don't know what UUID a given filesystem is using, use "tune2fs":

$ sudo tune2fs /dev/sda2 | grep UUID
Filesystem UUID:          3246c760-03c4-46bf-9d67-c9aea9b68318

With LVM/DM-raid it's the same. Each "part" has a UUID: the PV, VG and
LV for LVM, and the physical disk and MD-device for DM. 

So armed with this information, it's fairly straight forward to upgrade
your /etc/fstab to use UUID instead of device names. I think Bryan wrote
something about labels - I'll really try to avoid using them for
anything but information; if you ever consider cloning a disk, a
duplicate label can bring havoc on your system.

> 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?  

Actually, there's not that many anymore. Only devices found to be
"active" plus a few kernel overheads like /dev/null are there. On my
system it's just over 200 - mostly because my laptop has tons of USB,
encrypted file system, video etc. attached to it. That's FEW. They HAVE
to be there - somewhere there must be a bridge between the software/OS
and the device. That's what the major/minor number is for. However,
they're no longer staticly set or reserved for vendors etc. - they're
more "type of" numbers than anything else now (actually, if you study
initrd you'll find it actually still creates a static /dev in ram during
boot - but instead of hundreds of devices, it's a small handful enough
to get your system loading init).

> I don't see a dir full of UUID's !! 

See above - it's there :)

> ( I'm just
> gooseing a little for a nice explanation).  And how does this
> work for hotpluggin' ( for cmhowes benefit) ?? 

That's what dbus deals with. Together with udev, when devices are
detected, messages are sent out so the different software can react as
things happen. gfs will pick up on messages about new devices, and "do
it's thing" to make it available on the desktop for you. 

> His fd ( flash drive)
> gets a name and he doesn't have to "mount it". 

Actually, he should only need to double click the icon.

>  Again, an overview 
> ( or good link ) to how this mechanism works would be useful.

I think Bryan's description is pretty good. Maybe the above will help
too.

> 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"
> postings ).

Actually, it's simpler now. Plug and play; you put your USB device in
the computer, and (if recognized) you have an icon (or more) on your
desktop, ready to use. No more thinking about major/minor mapping,
hardwire IRQ/Ports etc. - that's the world the old static /dev came out
of.

> 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 !  

SCSI was ideal as a prototype because it already had support for
hotplugable devices. So no need to rewrite a new block protocol. That's
why everything is an "sd" now a days. Even though your flashdrive has
never seen a scsi controller :) 

> 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.

Wikipedia has quite a few articles on this. It's fairly straight
forward. Also, the kernel documentation covers this too. Even the
mailing list here has people who can provide the information - provided
you ask a question, and not simply state false "facts".

-- 
Best Regards
  Peter Larsen

Wise words of the day:
We are MicroSoft.  You will be assimilated.  Resistance is futile.
	-- Attributed to B.G., Gill Bates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://calypso.tux.org/pipermail/novalug/attachments/20100311/dd48ecba/attachment.bin 