From: 65381::LEDERMAN "B. Z. Lederman" 18-OCT-1996 07:04:17.88 To: STAR::EVERHART CC: Subj: Must have put your address in wrong From: STAR::US2RMC::"EVERHART@arisia.gce.com" "17-Oct-1996 2001 -0400" 17-OCT-1996 19:59:30.19 To: star::lederman CC: Subj: RE i/o h&k talk From: SMTP%"MAILER-DAEMON@mail1.digital.com" 17-OCT-1996 19:05:05.87 To: EVERHART CC: Subj: Returned mail: Host unknown Date: Wed, 16 Oct 1996 18:01:03 -0700 From: Mail Delivery Subsystem Subject: Returned mail: Host unknown Message-Id: <9610170101.AA07326@mail1.digital.com> To: EVERHART@Arisia.GCE.Com ----- Transcript of session follows ----- 550 pirulo.enet.dec.com (smtp)... 550 Host unknown 554 ... 550 Host unknown (Valid name but no A or MX) ----- Unsent message follows ----- Received: from gce.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA09340; Wed, 16 Oct 1996 17:53:19 -0700 Date: Wed, 16 Oct 1996 20:53:02 -0400 (EDT) From: EVERHART@Arisia.GCE.Com To: lederman@pirulo.ENET.dec.com Message-Id: <961016205303.62@Arisia.GCE.Com> Subject: RE: Hints and Kinks comments 1. why RAH/WBH mode is faster. Basically RMS does all the controls behind your back to handle ASTs. There may in fact be ways this could alter something, but its ast traffic's pretty well in exec mode like the rest. The flow goes thru a godawful loop when NOT using asynch I/O to wait for asynch completion. Asynch finishing bypasses the loop and much screwing around for buffers AND overlaps I/O. The RMS folks don't see any way it can affect anything. I said it'd need to be tested...this has not been well looked at. The magtape skipfile stuff is just being reviewed & tested (works ok but there's nervousness due to gryphon schedule). It'll need to be described somehow, though not in rel notes...something later. A factor of 100 in finding files (speedup on DLTs) is too big not to let customers have. As for third parties, this is generic stuff and a serious criticism of what might be done. A particular third party can disclaim using processes but I know of some that do, or at least did at one time. I don't think I know of try to use VMS locks, but have heard exec software has a HECK of a lot of lock traffic. The need to capture all disk entry points is because dkdriver, at least, is perfectly capable of grabbing IRPs off its input queue with explicit REMQUE instructions buried in the driver itself. If you want to control and cache all I/O, you need to control all entry points somehow. DUdriver may have such behavior...I don't know. Much of this got added in dkdriver because of support for tagged command queueing. DK tries to keep things queued in the device or in the port driver to minimize delay in getting to the next IRP. Thus a simpler intercept that only bothers with startio will be subject to flakiness under load or cluster state transition or mount verify. This is only so if you intercept an existing UCB; these considerations don't apply the same way to strict layered drivers like VD:, where there's a separate UCB. The point is that these cachers can work OK, but that designing them is complex enough that it is also easy to get wrong in subtle ways. You'll be giving folks good things to ask of sales folks. In designing for intercepts the key is to remember that once something gets onto the input queue of a class driver, it can be pulled off at any time, so you need to do whatever you want before an IRP is put on like that. As for optical disks, DKdriver will support r/w opticals pretty well. Also FAVOID will be on freeware V3. You may need to reassemble the thing's executables from macro (compile on alpha), since the kitinstal has a couple bugs and not all vms versions are covered, but favoid will alter extends to grab 1/n of the file's current size when extending, default is 1/4. (With limits so it never grabs too much of a disk's free space etc.). WORMs are "supported" by OSMS, which has cluster problems as I hear. It is possible to support WORMs by a virtual disk too, that won't allow delete, won't allow open of an existing file for write maybe, and which will have a fence. Basically the idea is you put indexf.sys and directories at the beginning of the disk, and store on a regular disk. Below block "n" (chosen so dirs - allocated big enough to hold more stuff to begin with - and indexf and bitmap all fit below blk n) you write to a real disk. Above, write to WORM. When things fill up, copy the first "n" blocks from the real disk store to the WORM and have real ODS2. FILE and a couple command procedures are all you need. Plus a virtual driver to do the separation and which will reject delete and maybe overwrite at FDT time. (Mine also checks directory size and won't let anything get entered in a directory file unless its EOF is at least 1 block below its allocated size.) Usable, but requires pre setup. BTW one reason 3rd party cachers have trouble with logical I/O is that it includes paging/swapping etc. When you have a process in there it's kinda hard to be grabbing log io too. Note that one advantage the 3p stuff has is they can track access cross cluster. I think VIOC only handles stuff open only on one node. When you boot, a cache that keeps stuff read by multiple booting systems in memory (perfect cache v3 did) can speed boot a lot. VIOC would be better if it didn't need to live in system space, would check FCBs to see what LBNs correspond to what files etc. Still the third parties need to be aware too that dkdriver can suck IRPs off in this way, and that the other entries can be used to ensure you get the right stuff. If any of them hear about irp$m_finipl8, that'll make the symposium worth having gone to, also. The remark is to make customers ask, not to scare everyone off of perfect cache, io express etc. Damfino what can be said about CDs. I'd love to have a multisession CD to play with so I could see how to get it supportable. But I need to have one first. There's some chance I may be able to do a virtual disk that'll reblock disks with non-512 blocksize; dkdriver should allow $qio access to these even though not for file structures. Not directly anyhow. What you have to do is read a (big) sector, write part of it, write (big) sector to update a block in those. (OSMS does!). You can imagine this is not a performance win. Spiralog MAY help this sometime; the story's not necessarily over, but if I were trying to use WORM, I'd be inclined to treat it as a sort of virtual TAPE and use my utility to make that look like a fast readonly disk, doing the blocking etc. internally as it does. Maybe even store data compressed. WORM as an archive medium in that way is possible to do useful stuff with, and not screw around with nonstandard ACPs and file structures (and have grief trying to serve them around a cluster, which is a problem now.) Consider my compressing disk package on freeware v3 or S96 sigtapes. It takes a couple files and makes them look like a disk, though they have just compressed data. With a little kludgery that storage could be put on WORM & accessed, and even store a larger disk image than the WORM might hold. It might just get done if I start fiddling... DKdriver allows r/w access to WORM now, so this sort of layer on top is perfectly feasible. Glenn % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA24080; Thu, 17 Oct 96 19:26:25 -0400 % Received: from gce.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA08324; Thu, 17 Oct 1996 19:15:12 -0400 % Date: Thu, 17 Oct 1996 19:14:47 -0400 (EDT) % From: EVERHART@arisia.gce.com % To: star::lederman % Message-Id: <961017191447.62@Arisia.GCE.Com> % Subject: RE i/o h&k talk