At least that's what I've found..
On Thu, 6 Aug 1998, Terry L Ridder wrote:
> Hello Everyone;
>
>
> Some dev_fs's cheerleaders are attributing abilities to dev_fs
> which do not exist.
>
> >From the updated dev_fs FAQ.
>
> <Begin Quote>
> SCSI Host Probing Issues
> <section>
> ========================
>
> <snip>
>
> Note that this scheme does not address the SCSI host order if you have
> multiple cards of the same type (such as NCR53c8xx). In this case you
> need to use the driver-specific boot parameters to control this.
> <End Quote>
>
> If you add a new SCSI controller to a system it is totally up to you
> to tell the kernel what order to probe the SCSI hosts. If you do not
> and you are using dev_fs /dev/sd/c0t3d0s1 and the SCSI host probing
> finds your new SCSI controller first you are out of luck. Because
> /dev/sd/c0t3d0s1 is no longer what you has before adding the new
> SCSI controller.
>
> So all these arguments that dev_fs "saves" you from the current
> SCSI rearranging are false. You still have to deal with the order
> in which SCSI hosts are probe.
>
>
> Stephen Frost wrote:
> >
> > > 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).
>
> But they do.
>
> >
> > Except that it is MUCH easier to find a physical disk if you know the
> > controller and target id of it.
> >
>
> <snip>
>
> >
> > 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.
>
> Please see above concerning SCSI host probing. Even under dev_fs if
> SCSI host probing order changes controller numbers will change, and
> Oracle would have the same problems.
>
> >
> > 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?
> >
>
> Please see above. You add a new controller it is up to you to indicate
> what the SCSI host probing order should be. Dev_fs has nothing to do
> with
> this. If you do not indicate what the SCSI host probing order should be
> the controller number can change.
>
> > > 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.
>
> It does break backward compatibility in a sense.
> As Theodore has pointed out in several postings which I quote below:
>
> <Begin Quote>
> Precisely. In Unix we have a very well developed abstraction for saving
> this kind of state: permissions, user/group ownership, modtimes, etc.
> It's called a filesystem. Tar is an unmitigated hack; using a C program
> helps hide the fact that what you're doing is a hack, but it's still a
> hack.
> <End Quote>
>
>
> >
> > 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.
>
> What are you talking about?
> Please show me where in any of the kernel scsi code where a letter is
> being used for a counter.
>
> <snip>
>
> >
> > 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
> >
>
> --
> Terry L. Ridder
> Blue Danube Software (Blaue Donau Software)
> "We do not write software, we compose it."
>
> When the toast is burnt
> and all the milk has turned
> and Captain Crunch is waving farewell
> when the Big One finds you
> may this song remind you that they
> don't serve breakfast in hell
> ==Breakfast==Newsboys
>
> -
> 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
>
-
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