From: AITGW::"MAILER-DAEMON" "Mail Delivery Subsystem" 24-FEB-1992 10:18:22.49 To: CC: Subj: Returned mail: Host unknown Received: by AITGW.DECnet (utk-mail11 v1.5) ; Mon, 24 Feb 92 10:16:40 EST Received: from ARISIA.dnet.ge.com by aitgw.ge.com (5.65/GE Gateway 1.4) id AA29667; Mon, 24 Feb 92 09:59:40 -0500 Date: Mon, 24 Feb 92 09:59:40 -0500 From: MAILER-DAEMON (Mail Delivery Subsystem) Subject: Returned mail: Host unknown Message-Id: <9202241459.AA29667@aitgw.ge.com> To: ----- Transcript of session follows ----- 550 ... Host unknown ----- Unsent message follows ----- Received: from ARISIA.dnet.ge.com by aitgw.ge.com (5.65/GE Gateway 1.4) id AA29388; Mon, 24 Feb 92 09:59:40 -0500 Message-Id: <9202241459.AA29388@aitgw.ge.com> Received: from ARISIA.dnet.ge.com by AITGW.dnet.ge.com (utk-mail11d v1.5) with MAIL-11; Mon, 24 Feb 92 10:16:34 EST Date: Mon, 24 Feb 92 10:16:34 EST From: EVERHART@ARISIA.dnet.ge.com X-To: AITGW::"goathunter@WKUVX1.BITNET" Subject: RE: FDDRIVER To: goathunter@WKUVX1.BITNET Thanks for the kind words. Actually slightly later versions are in the F91 tapes, and also on wuarchive.wustl.edu in systems/misc (a zoo archive has all the vd/fd stuff). I just recently put the vd/fd stuff into wuarchive. Actually, there is another package I've been looking at recently...Paul Sorensen's CDDRIVER, which adds cache to a local disk. Now, that's a NICE thing to have, and works well with fd: or vd: units. However, it has no clue about clusters as written. It steals the startio vector of a driver, manages disk access by monitoring this. When another node goes and writes some block that is cached via MSCP, the CDDRIVER cache is unaware of this, allowing bitmaps to be corrupted by having updates from other nodes get lost. The interesting thing is that such a driver COULD be taught... One simple minded way would be for a driver caching some block range to take out a lock on that block range which other cache drivers would try also, so that a cache could be invalidated on a write. Adding a block to a cache would require a lock on it, and presumably the operation on that block would stall until the lock was available where a write to a block was to be done. The advantage of this is that blocks are locked, and this is what CDDRIVER knows about. The disadvantage is a bunch of extra lock manager traffic. It occurs to me that anywhere VMS cares about interlocking, there must ALREADY be locking traffic coming into the processor, and if one could have CDDRIVER peek at it, CDDRIVER could invalidate its' local cache whether or not any cooperating CDDRIVERs existed at all other cluster nodes. Also this would induce NO added inter-node traffic. The difficulty I see is that the existing lock traffic is probably file oriented, and a translation to LBN may be needed which could be a pain in the neck to do (even though window blocks would probably exist in kernel space to cover the regions of interest where a cached block needed to be invalidated.) Do you happen to know any particularly good places to start looking for such functions? I've been staring at dudriver listings for clues about how SCS works, and mean to go rooting around for lock manager internals to see if I can satisfy my curiousity. I'd not mind this sort of info flowing around. Incidentally, CDDriver appeared on the Fall '89 VAX tapes (under [.aepsc]). Please forward any of this to the list if you think it appropriate. Glenn Everhart Everhart@Arisia.dnet.ge.com