lkml.org 
[lkml]   [1998]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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

    \
     
     \ /
      Last update: 2005-03-22 13:43    [W:4.571 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site