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