[Info-vax] HBMM

[Robert A. Brooks]

On 10/16/2011 6:01 AM, Phillip Helbig---undress to reply wrote:

> If I understand things correctly, if a node with such a disk mounted
> unexpectedly goes down, which would ordinarily produce a merge, then I
> will now get a (quicker) minimerge as long as one of the nodes with a
> bitmap is still in the cluster---right?
	Yes

> I don't want to try it for fear of screwing something up, but what would
> happen if I issued the same SET SHADOW command for a system-disk shadow
> set?  (I know that this is normally specified in MODPARAMS.DAT.)
	You'd get bit maps for the system disk if you issued a similar command 
targeting the system disk.  Similarly, you can disable it at will using 
$SET SHADOW

> Are the defalts generally OK, or is this a case like INIT/HEADERS where
> the default is really bad on a modern system?
	You are apparently running V7.3-2.  For the subsequent released
version of VMS (8.2), the reset threshold was raised to 1,000,000. With 
a reset threshold of 50,000, you will get more frequent sub-second write 
stalls to reset the bitmaps.  With a 1,000,0000 threshold, you'd get 
*slightly* longer mini merges (an increase of a second or two, at most).

> Is this information stored on the disk somewhere, in which case it would
> survive a cluster reboot, or not, in which case it presumably won't (and
> thus needs to be specified somewhere in the startup sequence)?
> (Presumably the policy applies to the shadow set and SHOW SHADOW will
> show the same thing (in this respect---obviously not for read cost etc)
> from all nodes.)
	Most folks "store" the information in command procedures that execute 
at boot time.  The actual "storage" for HBMM policies is clusterwide 
logical names, so the data is saved as long as at least one cluster 
member survives an outage.  Doesn't need to be the same member; any one 
member per "event" is sufficient.


  			-- Rob