Messages in this thread | | | Date | Fri, 7 Aug 1998 13:53:14 +1000 | From | Richard Gooch <> | Subject | Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???) |
| |
Terry L. Ridder writes: > Hello Everyone; > > Some dev_fs's cheerleaders are attributing abilities to dev_fs > which do not exist.
And vice versa.
> >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.
Incorrect. If you don't open your box and fiddle your controllers, you are safe from SCSI rearranging. By far the most common operation is that a SCSI device is removed/inserted. Moving controllers around is far less common. A typical situtation is where you have just one controller, but devices are from time to time removed/inserted. The single controller situtation would constitute the bulk of SCSI systems.
> > 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.
Perhaps the ones you talk to do. Other don't care about the new names, or are enthusiastic.
ObMantra: no-one is forcing you to use the new names.
> > 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.
Physically moving controllers around is far less likely. Furthermore, the devfs FAQ is quite up-front about it: I have not attempted to hide the issue.
> > 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.
Please see above. Fiddling your controllers is much rarer. Therefore the common case of removing/inserting devices is greatly helped.
> > 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>
And as I have said, if there is sufficient demand, I can add persistence to devfs itself. This is a side issue to the basic concept of devfs.
> > 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.
drivers/scsi/sd.c: sd_devname()
> <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.
Conveniently ignored, I note. He raises a valid point.
Regards,
Richard....
- 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
| |