From:	MOVIES::MOVIES::PALMER "OpenVMS Engineering, UK - DTN 824-3349  02-Jul-1996 0942 +0100"  2-JUL-1996 04:57:59.09
To:	STAR::EVERHART
CC:	PALMER
Subj:	RE: Cache in vms

Hi Glenn,

Many thanks for sending me your ideas. For the first version of the cache,
the intention is to provide a high performance VBN cache that solves many
of the problems of VIOC (e.g. no caching under write sharing, fixed max
sizes etc etc) as well as providing new features for ODS-2 like
write-behind caching. The default behaviour needs to be write-through
though except when RMS is already doing deferred write.

To provide the features we have committed to, an LBN cache is not an option
as we need knowledge of files. The cache is being designed to require the
minimum amount of file system support with a view to possibly implementing
a smaller LBN cache from the same code subsequently.

The idea for a disk based cache is very interesting, but I think its
outside the scope of the work we are looking at here I'm afraid.

Thanks for sending me your thoughts. I appreciate you taking the time.

Julian


From:	STAR::EVERHART     "Glenn C. Everhart 603 881 1497"  1-JUL-1996 16:19:00.01
To:	movies::palmer
CC:	
Subj:	Cache in vms

    Hi there...

    Just some ideas for cache.

    1. If you track back thru window blocks you can find what file an
    LBN access is for (if it's open). Assuming you cache only virtual
    I/O, this allows you to get data for files open only for read
    in the cluster. If you get an MSCP request to read a block from
    some other node, this can occasionally be a win when several
    systems are booting at once or otherwise accessing a common file.

    2. Where you have very slow devices (e.g. tape filesystems, opticals,
    jukeboxes, even HSM files) it can be a moby win to have a disk cache
    ON ANOTHER DISK. You have to synch the block map when it's changed
    from anywhere, but data access does not have to be synch'd since
    it can be automatically visible. This can also be handy in that
    it gives a simple way for directories on the slow disks to
    be cached, with gigs of cache, w/o taking much real memory, and
    regardless of whether all files are. Kinda happens automatically.

    I have a design (and early beginnings of code) for this that I did
    using intercept techniques before coming to DEC.

    The cache should be LBN oriented, so any file structure can use it,
    and can also give a simple way to put cache of a, say, spiralog
    disk onto an electronic one.

    Arrange to do periodic flush back to real disk and not bother
    with writethru (since the data goes to nonvolatile storage on
    the cache!) and you can use it to write WORMs, using badblock
    revectoring on the WORM to do remapping of what is overwritten,
    and doing it only rarely.

    Also very handy for making jukeboxes full of disks look like one or
    two disk volumes (almost) for a pc...

    Another thing it might permit would be a kind of soft directory
    scheme that would in essence allow one directory structure to cover
    many disks using a soft-link technique, while keeping the disks'
    individual filestructures intact. That's a bit off the exact topic,
    and would need a somewhat different intercept to do right, but
    it would mean that someone could treat a disk farm as a single
    structure except for backup, when it could be individual ones.
    Volume sets are almost this way, but they lack viability as single
    disks.

    Maybe you'll want to know more, maybe not...

    Glenn C. Everhart
    dtn 381 1497
    VMS Engineering