[Novalug] Device naming

Peter Larsen plarsen@famlarsen.homelinux.com
Thu Mar 11 21:09:50 EST 2010


On Thu, 2010-03-11 at 15:05 -0800, Walt Smith wrote:
> Peter and Bryan,
> 
> 
> Thanks for the detailed answers.  One reason for me asking was so
> that Alan, myself and others might know a little more about why the 
> present filesystem is the way it is.

A file system is a file system - a device is a device. Those are two
very different "animals". Some devices have file systems, some do not.

> While Alan stated some of his research, and an opinion, I 
> heard the following which I believe are questions, and summarizes
> to:
> 
> 1.  how are drives represented ( and identified ) in fstab ?

More misunderstandings. "Drive" is a windows term. Linux talks only of
mount-points. /etc/fstab defines the mount-points to be made during
boot. It doesn't "create" anything - it's a simple datafile that "mount
-a" reads during boot, to identify what to mount automatically.

That said, the sample I showed is how you refer to a device (which in
this case must contain a file system). Beside that point, I don't
understand your question.

> 2.  how do I make used of UUID in /dev/disk?

The commands that take UUID as a device identifier can use the UUIDs you
find in /dev/disk/by-uuid. There's quite a few of them. The point of a
UUID is that pretty much everything else about the device can CHANGE.
The UUID will not. So where you would otherwise refer to a /dev/sd? you
should UUID.

> 3.  why is the device ID of the boot drive not the same as data drive?

It's two different file systems (partitions if you will). For now, with
the current version of grub we separate boot out - because grub doesn't
understand LVM yet. That's just a matter of time before it will, and
when that happens, we'll get rid of the separate boot partition.

> 4.  Why does my data drive have 2 entries.

It has two aliases. Which one you want to use, is up to you.

> Alans excerpt for the above specifics is below.
> 
> I might point out that Torvalds at one point put the quash on
> naming new devices which trying to work out a system.  I believe
> that hot plugins were a separate issue for a time and then consolidated
> with the "new" fs.   Timing wise, Alan still thinks the system is 
> relatively new ( and I know exactly how he feels! ). Did it happen
> sometime around/before the 2.4 kernel.  Maybe someone could place a
> date/version on it ? 

Define "new". If you're still using a 2.4 kernel, pretty much anything
done in the last 6-7 years is "new" to you.

> However, to add a wee bit of data historically for this discussion,
> major numbers were at one time 8 bits and minor numbers were 8 bits:
> not enough to handle expected growth.  If one manufacturer of a device 
> (having a major number) wanted to have a number of variants, or, say,
> 300 com ports in one box, he was screwed.   Looking in /dev/ I might 
> hazard they are *now* 16 bits each ( ???  ), and I see that UUID's are 
> 128 bit.  (Just as a bit of comparison).. 

Well, I had to check. According to the kernel, it's defined DIFFERENTLY
depending on the subsystem. I see a few u8 but I also see int, u16 and
u32int now. Strangely inconsistent - but there are definitely aspects of
the block device modules that support > 255 for major/minor. "msdos_fs"
does not - noooo surprise there.  "fuse" uses u32, and that seems to be
more or less our defacto driver for USB and other plug/play devices like
that. 

I haven't really looked at mknod for years now (how I miss my simple raw
devices - NOT!) so I hadn't noticed the support for higher numbers.

> I think Alan has a point, though, about his desktop.  
> I tend to agree.... except I also accept the fact that ram and disk space cost is getting "smaller"...  and the hypothesis might be: 
> "why should a desktop with limited capability have a very complex 
> software structure  that takes a lot of resources?  Why not have a 
> static filesystem and get rid of a lot of software ?   

For lots of reasons. Abstract layers gives stability and flexibility. It
means that to improve something, you don't need to redefine all the
details, but you can simply add your code at a higher level. Newer PCs
have tons of devices in them; even our servers come with USB ready
plug/play. LOM cannot be done without hot-plugable features. So there's
a need for 'complexity' as you call it. I still will argue, that this is
simpler. Simpler to use, and simpler to manage. There are new components
yes, but it's structure is more straight forward while still providing
functionality to support a modern computer and even embedded devices.

> No, I'm not 
> trying to start a flamewar- ( think of it as rhetorical - past
> Linux's didn't have dynamic filesystems !!! )

We're talking ancient past now. The idea of a static /dev is quite old
(in IT terms).

> I do like the way linux is evolving.  Since CPU speeds aren't 
> increasing,  people ( bosses ) need ( want ) to buy boxes with 
> more "cores" (cost).

Actually, the speeds are increasing - the MHz aren't - but that doesn't
mean the cores doesn't perform better/faster. In other words, there goes
more into the CPU speed than it's Mhz.  Besides, more cores should be a
lot more efficient than single core systems as long as your application
is designed for multi-threading. As you point out, we have more and more
"stuff" running concurrently.

> Would someone care to comment about the resources an embedded linux
> uses in a very small form factor? yes yes YES !! you MAY accuse me
> of changing the subject !!

Depends on what type of embedding. My little Roku box has lots of plugs
for video and audio but no USB. My BlueRay player has a USB plugin, so
does my DVR. Our switches, KVMs and routers also have plugin features.
So there's still a need to handle plug-and-play and even hot-plugable
devices. But if CPU and memory is at a premium which it usually is for
embedded devices, you can still hardcode your /dev/ to a staticly linked
kernel. You're simply locking yourself into what type/vendor devices you
support. And for embedded systems that may be exactly what you want.
Then again, it may not :D 

> 
> Walt......
> 
> 
> ===============
> 
> 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. =\

Which is why we use UUIDs. They're written onto the filesystem (on the
disk) so they won't 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.

You wouldn't use that for new drives. See previous descriptions about
"new drives" are detected and used.

> On my existing system that is still running an old linux kernel, the
> device ID of my boot drive is:

That's really the major issue. If your kernel isn't even 2.6 - you're 7
years behind already. Things have really changed since then. Simply use
the UUID which is part of your filesystem - assuming Bryan is right (I
really don't doubt he is), there should be support of UUID= in your
mount version. I do recall some bugs early on with UUID support so you
may want to verify that first.

> 
> ata-ST380013A_5JVA01L2
> Which is correct...

Remember, these are just aliases. There's really nothing that's
"correct" here.

> But the device id of my data drive is:
> 
> scsi-SATA_WDC_WD3200AAKS-_WD-WCAT11129455
> Which is wrong because I don't own any SCSI hardware. It should be:
> SATA-WDC_WD3200AAKS-_WD-WCAT11129455

It actually should list them as BOTH - everything is using the SCSI
approach on the OS side - it's a common interface. I even have "virtual"
devices that represent themselves as SCSI devices. Even scanners show up
as "scsi".  

> WTF??? My data drive has two entries in there, the other is:

Right - it has two aliases. The kernel's device driver doesn't care if
you use a scsi/ata interface. How cool is that?

-- 
Best Regards
  Peter Larsen

Wise words of the day:
Problem solving under Linux has never been the circus that it is under
AIX.
	-- Pete Ehlke in comp.unix.aix
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.firemountain.net/pipermail/novalug/attachments/20100311/bebc0af4/attachment.asc>


More information about the Novalug mailing list