From: 3049::"rick@rdperf.com" 20-DEC-1996 14:02:39.65 To: row::Everhart, marty@symark.com CC: Subj: DKDRIVER & Device I/O Intercept Glenn, Let me introduce myself. I am Rick Cadruvi the co-author of the original I/O Express and author of Cache Manager. I also wrote or co-wrote Diskeeper, Dynamic Load Balancer, Dynamic Tape Accelerator, and several other VMS system software products. My experience with VMS goes back to pre-V1.0 field test. I have been doing VMS system programming since 1978. I was forwarded some comments attributed to you (see end of message) about problems with device I/O intercepts via DDT$*_START* and DKDRIVER. I have several questions: 1. When do expect a fix that forces DKDRIVER to at minimum initiate all IRPs via DDT$L_START (DDT$PS_START_JSB or DDT$PS_START_2 on AXP/VMS)? 2. Will this be a patch made available for older VMS versions? 3. You ellude to a possible workaround a product could implement. Could you provide me some ideas as to how you would get around this problem? 4. If I could shield DKDRIVER from UCB$V_BSY could I trust that DKDRIVER's setting of UCB$V_BSY would be be short lived enough and synchronized such that no new IRPs would appear on tha I/O Wait Queue (UCB$L_IOQFL)? I appreciate your help in this matter. 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%"marty@symark.com" 19-DEC-1996 20:41:18.97 To: rick@rdperf.com CC: Subj: RE: Cache Manager & SCSI >You sent me a message a couple of weeks ago about the SCSI driver (DKDRIVER) >and its use of IOWAITQ IRPs without queueing them to the start I/O routine. > >Could you get details on this including when the changes that cause it >to operate that way were made? > >Also, as I recall the developer mentioned that there might be a clever way >of working around this. Could you find out what that was? > >This should prbably be done with direct communication to the developer rather >than over a newsgroup discussion. Here's a copy of the original message I sent to you. My feeling is that we would both be best served if you contacted Glenn. That way you could ask him what he meant and get the answer directly, instead of having both channels of information funnelled through me (which is sure to induce translation errors). [original message follows] From: SYMARK::MARTY "Marty Kuhrt" 20-NOV-1996 13:00:40.43 To: RICK CC: MARTY Subj: FYI, SCSI I/O interception Hiya, Saw this article in comp.os.vms and thought it might interest you. It's written by Glenn Everhardt, who, as I understand it, is the SCSI device driver guy for VMS. [stuff about his mirroring software on the freeware CD snipped] By the way, a generic WARNING. Any product that does virtual disk, mirroring, etc. by trying to steal underlying start-io entries WILL corrupt SCSI disks handled by DKdriver if the load gets heavy enough or anything causes the dkdriver underlying code to have to declare itself busy. This cannot readily be worked around in the current code base. (I'm fixing that but the fix isn't ready yet). The problem is that dkdriver pulls IRPs off its queue without going thru the standard entries, and you can't catch IRPs before they get onto the queue reliably with current VMS (except by some really error prone hot patching techniques in the bowels of VMS that are likely to break with mods to the system!). Packages that leave pre-existing device names alone and have you continue to use them as the devices, where you can start them with the devices already in existence & use, are likely to be implemented like this. With older drivers, or under non-extreme load, the problem might not show up, but beware. If a vendor has something like this, DON'T BUY IT UNTIL THEY EXPLAIN WHY THIS IS NOT A PROBLEM WITH THEIR IMPLEMENTATION. The problem can be solved, but they need to be able to understand it and give a response. (There is one way that is even likely to be somewhat robust, but could hit i/o performance all over the system if extreme caution in its use is not followed, or in a worse case cause crashes.) Where the package gives a new device name (as e.g., vddriver does, or the DEC shdriver does) this is not an issue. Those needing further info may write me. Glenn Everhart Everhart@row.enet.dec.com ================== RFC 822 Headers ================== Return-Path: symark!symark.com!marty@netcom.com Received: by spia.rdperf.com (UCX V4.1-12, OpenVMS V6.1 Alpha); Thu, 19 Dec 1996 20:41:13 -0800 Received: from symark.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id UAA24665; Thu, 19 Dec 1996 20:35:18 -0800 Received: by symark.com (DECUS UUCP /2.0/2.0/2.0/); Thu, 19 Dec 96 18:40:34 PDT Date: Thu, 19 Dec 96 18:40:34 PDT Message-Id: <009AD164953A4600.202000BC@symark.com> From: "Marty Kuhrt" Subject: RE: Cache Manager & SCSI To: rick@rdperf.com X-VMS-Mail-To: UUCP%"rick@rdperf.com" X-VMS-Mail-CC: MARTY % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA12273; Fri, 20 Dec 96 13:51:48 -0500 % From: rick@rdperf.com % Received: from SPIA by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA23305; Fri, 20 Dec 1996 13:43:01 -0500 (EST) % Date: Fri, 20 Dec 1996 10:32:41 -0800 % Message-Id: <96122010324185@rdperf.com> % To: row::Everhart, marty@symark.com % Subject: DKDRIVER & Device I/O Intercept % X-Vms-To: SMTP%"Everhart@row.enet.dec.com" % X-Vms-Cc: MARTYK,RICK