From:	SMTP%"EVERHART@arisia.gce.com" 29-DEC-1994 09:56:07.70
To:	EVERHART
CC:	
Subj:	re: Virtual I/O cache and Page Faults

From: EVERHART@arisia.gce.com
X-Newsgroups: comp.os.vms
Subject: re: Virtual I/O cache and Page Faults
Message-ID: <941229094718.64@arisia.gce.com>
Date: Thu, 29 Dec 1994 9:47:18 -0500 (EST)
Organization: Info-Vax<==>Comp.Os.Vms Gateway
X-Gateway-Source-Info: Mailing List
Lines: 57
To: Info-VAX@Mvb.Saic.Com

The basic problem Mr. Mueller is seeing is that page faults are not
virtual I/O (which means read/write virtual block at $qio level). Virtual
I/O has to do with I/O to open files.

To cache logical I/O (including pagefaults) you need a logical I/O
cacher. While Paul Sorensen's CDdriver has been put on the VMS sig
tapes for VAX, it is not (at least not yet) ported to AXP. However
it is a logical block cache program. It works by intercepting driver
start IO and does block caching at that level, not by looking at
cluster locking etc. to synchronize a cache.

A virtual I/O cache can work by looking at FCBs and WCBs in memory to
figure out what blocks that it sees activity for correspond to what
files, or can use the WCBs in I/O activity directly for this purpose,
and can use the normal cluster lock manager to figure out when
someone tries to open one of the files it has parts of cached for
writing, thus invalidating the cache. A logical block cache on a cluster
has to use its own set of locks or other communication to figure out
when to invalidate a cache if there are multiple paths to the data...
particularly if these are not mediated by a VMS CPU (as in HSC-connected
disks). For virtual I/O, the locks already exist per file (if one
wants to go that way). Note too, that any cacher that tries to use a
process anywhere in its decision path, even off the critical path,
can avoid risk of deadlock by just not trying to cache paging I/O, but
if the paging I/O is to the process that is part of the cacher, a number
of deadlock conditions could arise.

Paul Sorensen's cacher is NOT a cluster cacher, and must run on the one
node where the disk is, and only works if the only I/O path to a disk
is via the CPU where the cacher is. In this case, none of these cluster
considerations apply, and effective disk speed can be greatly boosted
by using the thing. I believe that this cacher (improved and made more
cluster usable by Jon Pinkley) could be ported to AXP without incident
since I've used a similar intercept (a skeleton intercept driver is on
the S94 sigtapes) on Alpha for a number of things now with no problems.

Someone just has to need it enough to do the work. It WILL boost
performance.

One final thing should be noted: virtual I/O cachers will become obsolete
when the new AXP filesystem comes out because they'll have a lot of
cache built in, and also because FCB, WCB, and lock internals are all
different for those filesystems. Indeed, adding a cacher on top of the
ones known to the new file system appears quite risky to me, since
it would be unknown to the file system and might unwittingly introduce
some new vulnerability to data loss in case of crashes.

A logical cacher like the Sorenson/Pinkley one on the other hand, within
the limits of its design, might still be useful. Word is the device
interface remains as it is.

I'd be willing to dig up relevant pieces of code to send to someone
seriously wanting & able to do a port, but they ARE on the sigtapes.
The CDdriver material was last on the Fall 1992 tapes, by the way.

Glenn Everhart
Everhart@Arisia.gce.com