lkml.org 
[lkml]   [1997]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: On the subject of the VFS layer (was Re: VFS questions)
> 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.

You contradict yourself within that mail several times. It would make the
current code even more complex and even less debuggable and bugfree.

> 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.

It would be the bare minimum band aid fix.

> >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.

No, and here you can see one of those things I told you about before.....

EATA compatible controllers like the DPT do not want to be fed with any
tags. The controller analyzes in the incomming "stream" of commands
and does the necessary tagging by itself. Weather the command ultimately
reaches a drive within a RAID array or a "normal" drive doesn't matter.

You have to look at such intelligent controllers as black boxes:
At one end you stick in an _IO-request_ and on the other end the box will
spit out a result or an error message.

If you've ever used a mainframe imagine a DPT controller to be a "little
brother" of an IBM IO-Channel. All this great logic that you want to apply
from the aic7xxx or NCR or Buslogic simply does not fit.

Or just imagine SSA hardware or a controller from Genrocco.........

> 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.

You can reduce this to something very simple:
DONE, RETRY, QUEUE FULL / TRY LATER and ERROR/COMMAND DEAD

DONE: Command finished
RETRY: Retry command, requeue
QUEUE FULL/TRY LATER: Command could not be queued, requeue
ERROR/COMMAND DEAD: An error occured, the command is dead, this
information must go up to the requester.

Then use routines like the current ones or your own to do the
timeout and error handling.

What you must realize is that the hardware is getting more and more
intelligent and will not stand still at the level of a Buslogic.

The current midlevel code has been suffering for a long time under
a tight skin syndrome where you can't controll the sideeffects
anymore. The solution is not to but in even more stuff into the midleve
layer, but instead to pull it out and symplify. There are no clean
layers. The code must be put back where it belongs.

Mike


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.050 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site