Re: On the subject of the VFS layer (was Re: VFS questions)

Doug Ledford (
Sat, 3 May 1997 21:35:08 -0500 (CDT)

On Sun, 4 May 1997, Michael Neuffer wrote:

> > Not to mention that when you split things out of the mid level code this
> > way, then you are talking about having the inherent problem of each driver
> > having to get this timeout logic correct on their own. You would no
> > longer have a generic scsi layer that (suppossedly) works, but instead you
> > would have "This driver properly handles timeouts, this driver flakes out
> > when a command times out" etc.
> Look above. This is exactly what we have today. Because of this
> the SCSI subsystem is only able to handle the streamline mass market
> controllers.
> > In truth, the only scenario you are bringing up that needs this kind of
> > control is on a hardware RAID controller that does some kind of live
> > rebuild for a lost device. Then you have the situation of having to wait
> > on commands to complete because the controller is busy rebuilding that
> > lost drive and handles your commands as it can. For non hardware-RAID
> > controllers (the vast majority of those out there :) this wouldn't buy us
> > anything since those controllers don't go around doing intelligent things
> > on the SCSI bus behind our back.
> This is exactly the problem, you will see more and more sophisticated and
> intelligent controllers in the future, and their behaviour will divert
> more and more from that of an AHA1542, basically the only thing that they
> have in common is that they process SCSI commands SOMEHOW. Any assumptions
> additionally to that will defintely lead to problems at some point.
> The only place where strategic decisions can be done are in the lowlevel
> driver. You can supply a set of generic routines for that for the current
> set of streamline controllers but anything else is a fatal mistake.

This is all fine and dandy in regards to streamline, mass market
controllers vs. intelligent RAID controllers (or some future controller
incarnation). However, you didn't even address the proposals I made in
the original letter for how these issues you are bringing up could be
handled. I assume that you are working on the DPT driver and this
particular behaviour causes problems. The long and short of it is, can
what I proposed be used to solve those problems in the DPT (or other
intelligent card) drivers? As someone working on the low level driver
code, you are in the position to provide that answer.

>From the standpoint of the aic7xxx driver, I know that a callin routine to
let us know that a command has timed out, and allowing us to provide a
suggestion as to the next course of action would be edvantageous even on
that streamlined controller. Currently, we issue one in every 200
commands to a particular device as an ordered queue tag in order to keep
any particular command from being placed too far onto the back burner as
part of the drives queue optimization. Knowing that a command timed out
would allow us to then send an ordered tag command to force the command to
complete without having to go through an abort/reset routine in order to
resurrect the command. This would also allow us to skip the once every so
often method of sending ordered queue tags so the drives could be more
efficient in how they handled tagged queueing. Could the same thing be
used under the DPT driver to solve these problems you are mentioning. As
a sidebar, I would consider it advantageous to only implement the
suggestion routine as oppossed to a full timeout mechanism. In this way,
you only have to write the logic that determines what should be done, and
not the logic to handle the timeouts themselves.

* Doug Ledford * Unix, Novell, Dos, Windows 3.x, *
* 873-DIAL * WfW, Windows 95 & NT Technician *
* PPP access $14.95/month *****************************************
* Springfield, MO and surrounding * Usenet news, e-mail and shell account.*
* communities. Sign-up online at * Web page creation and hosting, other *
* 873-9000 V.34 * services available, call for info. *