Linux-kernel mailing list archive 1998-31,: Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)

# Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)

Stephen Frost (sfrost@snowman.net)
Thu, 6 Aug 1998 13:09:34 -0400 (EDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Mike A. Harris: "Re: IDE drive data transfer rates, kernel optimization?"
- Previous message: Jiann-Ming Su: "sx164 floppy solution (fwd)"

> I do not know about it similarity to other UNIX's (other than SUN/SCO) but
> /dev/sda is definately simple. As far a company goes they are not going to
> care if their drive is named /dev/sda or /dev/dsk/sd/c0t0d0u0 (whatever).

Except that it is MUCH easier to find a physical disk if you know the
controller and target id of it.

> This will not affect companies one way or another; other than the fact that
> /dev/sda saves a few seconds typing and prevent alot of typos. (Note: very
> few, if not any, Sun/SCO admins that I know easily remember the device names
> to their SCSI disks. Usually they curse and then look it up through vfstab
> or /dev/dsk. This wastes some more minutes) Where naming can and probably

SUN has it's own problems w/ that damn /devices directory and the
fact that they use those names in their log files. I've discovered that
the /dev/dsk/c0t0d0s0 way of expressing a disk is VERY usefull in large
machines. Yes if you have all of one SCSI controller and maybe two drives
the /dev/sda solution is fine, but when you have 6 controllers and about
30 drives, as well as a raid array w/ another 36 drives in it, I'm sorry,
but /dev/sda would not cut it.

I've got another machine w/ 5 SCSI controller in it, of which
only 4 are used and I've got a total of 30 disks, this system is running
a nice big Oracle system. Oracle at least in the past for me does NOT
like it when/if the name it uses to access a drive changes. If you are
using raw disk mode then in my view you basically HAVE to have something
like /dev/rdsk/c0t0d0s0. You could set the database up using /dev/sda,
but if you ever changed your configuration, oracle would probably die
and you'd probably lose any data stored on any disks that had their name
changed.

My only concern about devfs would be how it assigns controller
number, I like some of the things about how SUN does it, like that the
controller number basically never changes unless you do some strange
stuff, is this true for devfs?

> will make a difference is in the user who is used to A:,B:,C:,COM1,LPT1,etc.
> This type of person would be more likely to curse not praise the verbosely
> complex names that devfs "perfers" to use. I agree that SCSI definately
> needs a change to support large numbers of controllers and disks but most
> other devices EIDE,floppies,serial ports, etc do not and changing their
> current simple device names only (after the only device names are removed,
> which they will if devfs is added) breaks backward compatibility and adds to
> the complexity of a Linux system. BTW, devfs is not consistant, at least
> not to Solaris and perhaps (I do not remember) not to Unixware either.

Except that from what I understand it doesn't break backwards
compatibility at all. EIDE I agree works okay the way it is w/ /dev/hda,
but that's mainly because it's consistent and the /dev/hda access point
doesn't change if you add or remove disks, it's directly associated w/
controller 0, master drive. Floppy drives are /dev/fd0, closer in my view
to devfs already than /dev/sda is.

Thinking technically, since when does someone use a letter as a
counter? You going to use a char in a for loop for your counter or an
int? For some very specific things where you want to say list off the
ascii character set you might do that, but I know I use an int when I'm
in need of a counter.

Admittedly, /dev/sd1 wouldn't work very well in this case, but
/dev/sd1s1 or something would at least be getting closer to usefull, but
it's ugly, and if you're starting down that road, you might as well go
all the way and say /dev/c0t0d0s0 or something similar. I don't use
different LUNs very often, so perhaps /dev/c0t0s0, that would tell me
the controller, target and slice where the error happened. The controller
and target would tell me what physical disk it was, which is much better
than having to guess w/ /dev/sda.

Another issue, what happenes when a drive doesn't respond to
SCSI probes? Happens all too often to me, and figuring out which drive
died would be MUCH harder to do w/ /dev/sda than w/ /dev/c0t0d0s0, not
impossible, but would certainly take a whole lot more time.

Stephen

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

- Next message: Mike A. Harris: "Re: IDE drive data transfer rates, kernel optimization?"
- Previous message: Jiann-Ming Su: "sx164 floppy solution (fwd)"