Comments are below. I have attempted to snip out as much as possible
for the sake of readability and to save bandwidth.
Richard Gooch wrote:
>
> Terry L. Ridder writes:
> > Hello Everyone;
> >
> > Some dev_fs's cheerleaders are attributing abilities to dev_fs
> > which do not exist.
>
> And vice versa.
I am not sure what you mean by this, so I will not even attempt
to respond to it.
>
> >
> > 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.
It is not incorrect. If a person adds a new SCSI controller to a system
and does not explictly state what the SCSI host probing order should be
there is absolutely nothing in dev_fs that would recognise this and
prevent SCSI devices from being identified as /dev/sd/c0t3d0s0
incorrectly.
This is no different than the current /dev where the person does
not take care in adding a new SCSI device. You have only now moved
the problem to the SCSI controller level.
Also, if and when I open a box up I am not doing it just to
"fiddle" with anything, I am doing so because there is a definite
purpose in doing so.
I disagree quite strongly. In a server it is for more likely that I
add or change a controller, than to change a hard drive.
I will also point out that a fair number of those who are using
dev_fs are using it in a multiple controller scenario.
<snip>
>
> 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.
Richard you are missing the point. It does not matter whether or not
anyone is "forcing" anyone to use the new names, it matters at least
to this one company in particular that if dev_fs goes in the kernel
they will have nothing to do with linux. It is their decision.
<snip>
> > 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.
I disagree quite strongly. Given the improved reliability of hard
drives compared to the early years, I am much more likely to add or
change
a controller, due to better scsi driver, better support from the vendor,
preventive maintainance, than change a hard drive.
>
> > > 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.
Richard, this is not a side issue, it is a basic design flaw in dev_fs.
It should have been there from the every beginning, not treated as a
"side issue".
>
> > > 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()
You are definitely playing wih semantics here Richard.
In drivers/scsi/sd.c (linux-2.1.114) there are no for loops, while
loops,
do loops, etc of any kind.
There are two sprintf's which do use 'a'.
Calling that 'a' counter is really stretching it.
>
> > <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.
I did ignore it because in my own mind have I am attempting to
comprehend the System Administration style of those that use this
as an arguement.
For nearly every system I am responsible for I have the following:
A log book which has in it:
What hard drive with vendor name, model number, serial number, scsi id,
which controller it is attached to, filesystem type, whether it is part
of a LVM group (HP-UX), md (linux), and mount point.
In nearly 92% of all cases just by going to the log book I am
able to tell exactly which drive, controller, etc is having problems.
I personally do not rely on /dev anything when troubleshooting a
problem.
Yes some people may consider it "old fashion" but I still put labels
on the hard drives which have nearly the same information as the log
book.
Also in 99.9% of the machines I am responsible for like machines are
configured always the same way.
So from my System Administration style this type of problem does
not present itself.
>
> Regards,
>
> Richard....
-- 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