From:	SMTP%"buda@star.enet.dec.com" 12-DEC-1993 14:36:46.89
To:	EVERHART
CC:	
Subj:	Re: Global buffers

From: buda@star.enet.dec.com (Mark A. Buda)
X-Newsgroups: comp.os.vms
Subject: Re: Global buffers
Date: 3 Dec 1993 20:41:33 GMT
Organization: OpenVMS Engineering
Lines: 95
Distribution: world
Message-Id: <2do89t$4a7@jac.zko.dec.com>
Reply-To: buda@star.enet.dec.com (Mark A. Buda)
Nntp-Posting-Host: STAR
Keywords: RMS, Global Buffers
X-Newsreader: mxrn 6.18-1
To: Info-VAX@CRVAX.SRI.COM
X-Gateway-Source-Info: USENET


In article <1993Dec3.093201.478@buckie.hsc.colorado.edu>, dwing@uh01.Colorado.EDU (Dan Wing) writes:

>>This is NOT true.  If there is a lot of writing, then the systems will
>>have to do the same number of I/O's as compared to having data in local 
>>buffers.

>Someone has to coordinate in-memory buffers with on-disk data.  This was
>quite a few years ago, but I believe VMS does this when you write by 
>informing other nodes that the data in their global buffer cache is invalid 
>(I don't recall if specific blocks are declared invalid, or the entire
>global buffer cache for the file), and when another node in the cluster
>needs to read data from its global buffer (which was previously made 
>invalide by a write by a process on a different node), it will be forced to 
>do a read from disk.  

The overhead for Global buffer and Local buffer for locks is basically the same.

The entire global buffer cache is not invalidated.

It works simplistically like the following where a process on each node does
the following work:


NODE A gets record 1
 - Lock is obtained (sequence number is set)
 - Read I/O is done
 - RMS saves sequence # from LVB in local structure

NODE A UNLOCKS record 1
 - Lock is converted to NL (Sequence number is is lock value block (LVB))

NODE B gets record 1
 - Lock is obtained (LVB contains sequence # from LVB)
 - Read I/O is done
 - RMS saves sequence # from LVB in local structure

NODE B UNLOCKS record 1
 - Lock is converted to NL (Sequence number is is lock value block (LVB))

NODE A gets record 1
 - Lock is obtained (LVB contains sequence # from LVB)
 - RMS compares sequence # it cached against sequence # in LVB -- finds
   match.  I/O is not needed because data is already in Global buffer cache.

*** This is a saved I/O across cluster access ***

NODE A UPDATES RECORD
 - Write I/O occurs
 - RMS increments sequence # in LVB

*** To invalidate all other cluster node members caches for this file, only
    the sequence # in LVB needs to be updated.  When another node needs access
    to the record, it will $ENQ the lock and then find out that it needs to do
    a write.  A node will only find out that it's data is stale when it grabs
    the lock, not before.  This behaviers uses a delayed invalidation
    technique.

NODE A UNLOCKS record 1
 - Lock is converted to NL (Sequence number is is lock value block (LVB))

NODE B gets record 1
 - Lock is obtained (LVB contains sequence # from LVB)
 - RMS notices that local cached sequence # does not match one in LVB
 - Read I/O is done
 - RMS saves sequence # from LVB in local structure

NODE B UNLOCKS record 1
 - Lock is converted to NL (Sequence number is is lock value block (LVB))

and on it goes...

The above is true of two processes, whether they are in a cluster or local
when using local buffers.

>Someone please correct me if I've got the mechanics of this behavior 
>incorrect.

See above! :-)

>I agree the number of I/Os to disk will be the same, but there will be more
>coordination between nodes to invalidate global buffers in the other nodes;

See above, please, as this is not true.

>if this coordination has to happen between lots of nodes, especially over
>slow links (Ethernet), and especially if "too many" RMS buffers are setup
>for the file, you could actually see performance degrade.  

Again, please see above, as this ios not true.


Hope this helps,
	- mark