From:	STAR::EVERHART     "Glenn C. Everhart 603 881 1497"  3-APR-1997 08:46:18.20
To:	SMTP%"ben21@advsyscon.com"
CC:	EVERHART
Subj:	RE: re: data corruption...

Ben, glad you got back to me. I believe it can and should be fixed (and
as I said, if I had been at Digital when this was going down, I think
it might not have.)

To a degree my hands have been tied in this area but there are certainly
ways to solve the problem. Forking and calling startio from the fork
routine for example. (There! now you know how to do it.)

The problem with what I've seen is that EVERY goddam one of the
schemes I've seen involves some additional overhead, and third
party apps aren't that well known; only one or two of us in here
have played in that arena as far as I know (and none of my stuff
uses that particular interface; as you probably know, all my virtual
disks just call the underlying driver, DEC's shadowing has a bunch
of special code to handle boot from shadowing device and so on, and
the DEC cacher (like so much else) has special code all over the place
to handle it. 

Personally I believe that the "add special case processing and
special fields to data structures ...like IRPs... to support this new
product" is the wrong architectural one. It has already led to far more
complexity than is really needed, and the main sustainer of that
philosophy at this point is fear of breaking someone's apps.

I'm working on some multipath support code now, which is simplest to
introduce as an intercept (instead of special purpose edits in EVERY
SINGLE DRIVER that might be involved now or any time in the future!).
So I want this fixed too, and a retrofit will surely be needed to
get this into earlier releases. There are however many fire drills, and
while I have an idea for a solution (and have tested that it causes
no crashes or hangs or other discernable problems), it still has a 
couple PALcode calls (which as you may know are like "speed bumps" for
the Alpha hardware). I'm hoping they can be removed but that needs 
investigation by several groups, not just SCSI, and a whole bunch
of testing, where resources are scarce. So I'm competing for those
and for the time of reviewers who have authority to say yea or nay
to this. Fortunately some of the folks at EDO in Scotland agree with
my architectural prejudices.

Of course, a bunch of us have assumed lots of stuff Digital never
really promised would stay the same; some more will be going on
in other areas next time out. None of this intercept business
was ever really guaranteed to work. What I'd like to accomplish with
multipath is to get something I can use, but also to define a STANDARD
WAY to intercept which will be DOCUMENTED and which someone won't
break in the future. The system I'm working with allows multiple intercepts
of the same entries, rapid location of intercept UCB from intercepting
code (or elsewhere as it turns out), clean insert/remove of intercepts
regardless of level depth, and cleanly defines FDT and startio intercepts
in nestable ways. It also provides a way (part of which is in the 7.1
code; I want to get the rest in but am blocked there too at the
moment) to get control at completion as well without detours through
one or two extra interrupts, i.e., blindingly fast. A test vddriver
version ran 25% faster using this, even with the non optimization it
had in other parts of i/o.

So this is being worked; I'm the guy working it.

As for the immediate issue, though, I'm not sure what the response would
be. Raise an IPMT case on behalf of all the third parties who use
start-io and it may help. Presently though I suspect that any dkdriver
patch that came out would come with some warning that it may perform
more slowly than the normal dkdriver, and there will be pushback on that
ground. However it would lend some credibility to my internal remarks
that this behavior screws anyone trying to grab I/O at this point. (I had
rather suspected from your literature & ads that you must be one of the
outfits doing this.)

I can understand in retrospect why this was done too. Jim Dunham (group
leader at the time) had no ISV experience, 6.2 was WAY behind schedule
and SCSI was being blamed, and they were getting kernel stack not valid
errors (nasty...you have to set your machine to restart on halt to even
get a crash dump) at load all the time, and the DKdriver scheduling
was very new, not that well understood (some key designers had left
the company during the build cycle and left Jim holding the bag for
their designs), and yet critical. 

We've already checked out the notion of using some macro-64 magic to
get around this; it looks like the result will be too complex
and special purpose to use, though, because of what the compiler
can and can't be told to do about the stack and call frames. (Also the
macro32 maintainer just moved, so that's in flux.)

I suppose the best you can do would be IPMT. It might get blown off,
but will at least raise some consciousness. In the meanwhile at least
you have the listings...I complained this time when I heard they were
censored & got them uncensored. Lord knows enough people need them.

I'm inclined if *I* wind up getting the IPMT to answer to turn it over
to the Powers that Be and ask if it wouldn't be ok please pretty with
sugar on it to release some dkdrivers for 6.2, 7.0, and 7.1 with
a workaround in them for the time being. Politically I don't think I
could leave it open too long (damn politics!) but if management approved
there'd at least be a way to get something out. You or anothe 3rd party
could always measure its thruput and quantify the degradation,which
hopefully would be small. If the battles about this were easier, this stuff
would be in patches on the net by now.

Glenn Everhart