> Hello Everyone;
>
>
> Some dev_fs's cheerleaders are attributing abilities to dev_fs
> which do not exist.
Considering I've never used it and am only offering up
ideas that to me would make it usefull I don't see a problem.
> 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.
I was asking if it did, not stating that it does.
>
> 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.
And I didn't write that, don't try and quote me on things I didn't write.
> >
> > 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.
Yes, and as such I feel dev_fs should be modified to save it instead
of probing on boot, as the way Solaris does it, which is the machine I was
talking about.
>
> >
> > 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.
As you can I hope read I was expressing a concern that devfs assigned
controllers on boot and I feel that is a problem, perhaps not a very big
one, but I feel it would be nice if it did. Again, I was ASKING how devfs
did it, because I didn't know.
> > > 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>
And again, in another post I was agreeing that it would be better
in the fs instead of in memory, perhaps you should try following the
thread? My comments here were mostly on the naming scheme, not how it is
implemented.
> > 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.
/dev/sda, 'a' means it's the first controller, right? That's
a counter in my view, doesn't matter where it is, just that it isn't
good.
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