From: 3049::"rick@rdperf.com" 23-DEC-1996 18:00:16.79 To: row::everhart, marty@symark.com CC: Subj: Re: DKDRIVER & Device I/O Intercept Glenn, I was not trying to rag on DEC about what happened. From my perspective I just found it incredible that no one thought about the consequences to the changes. I know that DEC has more to worry about than third party vendor products (especially system products). However, many LARGE DEC customers can't live wihtout the poerformance they get from their third party caching products. I don't think how it is solved is really a serious issue on the surface for people like me. Changing our code to use some other intercept means is not a big issue. Obviously I would prefer to just install a new DKDRIVER and voila the problem is solved. However, sending out a new version of our software as well is fine. It is, however, extremely important to get a V6.2, V7.0 & (when shipped) V7.1 solution ASAP. As to what a caching product needs for intercept: All we really need to be assured of is the ability to get ALL IRPs (at least the write & DSE style ones) at Start I/O (or thereabouts). We also need to regain access at I/O Posting. Currently we do that using IRP$L_PID modifications. That is not the best since we get the IRP at IPL$_IOPOST instead of at IPL$_IOLOCK. As a result there are special problems that arise when dealing with I/O Errors. However, we have all had to solve this and we (I gues I should me) are not looking for a solution there. We just have to be able to guarantee that we see ALL write type I/Os. Of course, we would also like to see ALL read type I/Os as well. I would be happy to take an updated image from you for V6.2 and/or V7.0 and modify my software to work with it and let you know how well it seems to work. I would even be willing to send you an updated version of my software to play with yourself. At the risk of seeming stupid, I was not totally clear about why re-forking (or creating new kernel processes) when restarting a newIRP would not work. Is it due to the complexity of DKDRIVER and what that would involve? Wouldn't reforking the new IRP allow for stack cleaning and therefore be safe? Is it a performance issue? Rick Cadruvi R&D Performance Group, Inc. 1180 E Patricia #102 Simi Valley, CA 93065 (805)520-4170 (office) (805)520-4173 (direct desk) (805)520-4169 (fax) rick@rdperf.com From: SMTP%"everhart@row.enet.dec.com" 23-DEC-1996 13:49:49.59 To: "rick@rdperf.com"@3049.ENET.dec.com CC: Subj: Re: DKDRIVER & Device I/O Intercept Re forking in dkdriver is not gonna help. It already is very heavily using kernel processes (not forks) and the problem is up ahead of that. The problem needs to be solved some other way I think, though I will keep your letter and see what might be made of it. A change in the i/o exec outside drivers is more what one needs...the main issue being that there are lots of kernel stacks already involved, but we have the basic loop of startio->reqcom->startio using calls in Alpha instead of jumps in Vax as well. I'm hoping that vendors who need altered bits will be willing to ship them as needed...damfino how to get them out sensibly any other way. Hopefully it'd be a pre-release of 7.2 stuff that nobody could very well claim was a problem. But as I've said, I only realized this was a problem quite recently and made my remarks in the hope that guys like you would get in touch so we can try to do something about it. However, right now you're not dealing with corporate DEC. Just me, since there are only a couple other folks around here who know about the problem and I can't be sure if any of them really appreciate in their guts what it means. Yet. I'd advise you to avoid trying to support dkdriver on your own, BTW, if you can get out of doing it. The goddam thing's complex enough now and it's not a job I'd want to wish on anyone. (Which is why I wanted to do path switching in a separate layer, btw.) I can't say yet what the official reaction to any of this will be; I am not in management anywhere. The technical end is another matter. It turned out to be OK for what I needed to just say I could catch every IRP when it got "to" the disk drive...either arrived in the queue or at start-io (when queue was empty). That may not be a model that'll work with caching. I'd like you to tell me if that's so or not. It certainly means there can be more stuff outstanding, but maybe it doesn't matter all that much. My mental model was that once an IRP is in the DK input queue it must be regarded as being in DK's hands, regardless of where it actually is with respect to the disk heads. (There are many other places they get queued internally lower down!! so you can't tell that an IRP at start-io is really any closer to execution.) BTW among my hacks are some that can speed up interception processing at the back end. Currently I have only lab code running for a path switch that uses the new intercept scheme...and I steal MV start/end, io cancel, aux entry, as well as start-io. A cacher probably needs to worry only about startio and pending io, and altstart if it likes, I'd expect. glenn ================== RFC 822 Headers ================== Return-Path: everhart@row.enet.dec.com Received: by spia.rdperf.com (UCX V4.1-12, OpenVMS V6.1 Alpha); Mon, 23 Dec 1996 13:49:42 -0800 Received: from us2rmc.zko.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id QAA22339; Mon, 23 Dec 1996 16:41:36 -0500 (EST) From: Received: from row.enet by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA08940; Mon, 23 Dec 96 16:16:43 -0500 Message-Id: <9612232116.AA08940@us2rmc.zko.dec.com> Received: from row.enet; by us2rmc.enet; Mon, 23 Dec 96 16:41:20 EST Date: Mon, 23 Dec 96 16:41:20 EST To: "rick@rdperf.com"@3049.ENET.dec.com Apparently-To: rick@rdperf.com Subject: Re: DKDRIVER & Device I/O Intercept % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA13849; Mon, 23 Dec 96 17:55:00 -0500 % From: rick@rdperf.com % Received: from SPIA by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id RAA20388; Mon, 23 Dec 1996 17:47:50 -0500 (EST) % Date: Mon, 23 Dec 1996 14:32:12 -0800 % Message-Id: <96122314321197@rdperf.com> % To: row::everhart, marty@symark.com % Subject: Re: DKDRIVER & Device I/O Intercept % X-Vms-To: SMTP%"everhart@row.enet.dec.com" % X-Vms-Cc: MARTYK,RICK