Messages in this thread | | | Date | Thu, 6 Aug 1998 13:09:34 -0400 (EDT) | From | Stephen Frost <> | Subject | Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???) |
| |
> 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
| |