This documents diffs between vddriver5.mar and vddriver5a.mar; use the latter please! Asnvdm6 was also updated. From: "Mark Pizzolato 415-369-9366" Subject: Re: magic disk To: arisia.dnet.ge.com!everhart X-Vms-Mail-To: uucp%"everhart@arisia.dnet.ge.com" X-Vms-Mail-Cc: MARK >Date: 28 Oct 91 19:24:30 GMT Funny you should post something about FDDRV stuff just now, I was just asking Jamie Hanrahan if he had your E-mail address a day or two ago. Anyway the reason I wanted to contact you is: I had gotten a copy of your FDDRV directory from somewhere a while ago (approx 1 year), and didn't end up doing anything with it until just over a week ago, I have one of the more modern large disk drives which I recently realized has several different use categories that are mutually exclusive in regards to efficient use and/or accessing space on the disk. (i.e. certain applications are fragmentation monsters constantly creating and deleting LARGE numbers of small files (~3k), while other applications ocasionally (weekly) create and delete while constantly accessing a small number (~3) of large (~30mb) files) I decided it would be best to keep the large files in a reasonably sized (100mb) virtual disk, so I created a 100mb file, and it took diskeeper 2 weeks and 4 days of CPU time (VS3100/M38) to defragment this 100mb beast into 1 extent. Yes, I know backup and restore would have been much faster, but I didn't realize that at the beginning, and I didn't have to bring anything down to achieve this. Anyway, once I had the large single extent file, I went and found your Virtual Disk stuff and unpacked the MAR.ZOO (Creation Date 21-Jun-1990). I started with VDDRIVER5.MAR (8-May-1990), and defined vms$v5=1, and built the driver. I then built ASNVDM6. So far so good. I then loaded the driver, created VDA0 and tried to assign the 100mb file the device. It didn't work (You know this already), since although the file was technically contiguous, it wasn't created with the CONTIGUOUS file attribute and ASNVDM6 depends on that. I probably could have shut down all other activity, and deleted the file and recreated it with the CONTIGUOUS attribute, but I didn't want to shut things down. I changed ASNVDM6 to check to see if the specified file is merely composed of a single extent, and if so, to use that extent, which handles both my file and a file created CONTIGUOUS to both be handled by a more general mechanism. I then got the VD working, tested it some, and moved the several 30mb files to it. I started the application up again and things ran smoothly for about a day when things got busy for the large files on the VD. Suddenly all of the processes referencing the several large files stalled. All of them were in RMS, and all but one could be stopped. The one that couldn't be stopped had one I/O which was still hanging on the VD's I/O request queue and the device was NOT busy. For some reason I had to reboot the whole cluster (the VD was cluster mounted), not just the node with the hung process to get things running again. I didn't have time to immediately look into, and fix, the problem so I had to let things run once again without intervention. I got back to it a day or so later when things once again got into the same hung state. I then looked into and fixed the problem with VDDRIVER. It seems that the special case of the Virtual I/O which needs to be hooked to the right UCB to have a proper window context at I/O completion, was keeping the device busy, until completion which was perfectly reasonable and correct, and once associated with the correct UCB, upon completion, was being completed correctly. What was not being done and ONLY comes up if one (or several) new I/O happens to arrive while the VD UCB is busy waiting for the original I/O to complete. This is what happened to me. Since the completion activities for the virtual I/O was not happening in the fork context of the driver, but as hook in I/O post processing, we were never doing a REQCOM on that request which would have handled the case of of starting other pending I/O. I made the necessary changes to VDDRIVER5.MAR to correct this situation. I'm attaching a VMS SHARE of both ASNVDM6.MAR and VDDRIVER5.MAR, please let me know if there have been any other fixes and/or enhancements to these programs. Thanks for giving us the original work and all your other efforts. -- Mark Pizzolato - INFO COMM Computer Consulting, Redwood City, Ca PHONE: (415)369-9366 UUCP: decwrl!infopiz!mark or uunet!lupine!infopiz!mark DOMAIN: mark@infocomm.com