[Info-vax] HBMM

[Phillip Helbig---undress to reply]

I finally set up HBMM with SET SHADOW on non-system disks, taking the 
defaults and specifying MASTER_LIST=*.  I now get something like this:

_DSA510:  Volume Label: USER
  Virtual Unit State:   Steady State
  Enhanced Shadowing Features in use:
        Host-Based Minimerge (HBMM)

  VU Timeout Value      3600    VU Site Value          0
  Copy/Merge Priority   5000    Mini Merge       Enabled
  Recovery Delay Per Served Member                    30

  HBMM Policy
    HBMM Reset Threshold: 50000
    HBMM Master lists:
      Up to any 6 nodes in the cluster
    HBMM bitmaps are active on JANDER,LEEBIG,MINNIM
    Modified blocks since bitmap creation: 14605

  Device $110$DKB400
    Read Cost            501    Site 0
    Member Timeout       300

  Device $170$DKB400            Master Member
    Read Cost              2    Site 0
    Member Timeout       300

  Device $150$DKB400
    Read Cost            501    Site 0
    Member Timeout       300

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?

For now, I don't want HBMM on system disks, because I then have to DOSD, 
which means I have to dump to a non-shadowed disk, which would be too 
much trouble at the moment.  (Also, the system disks are smaller than 
most other disks so a full merge doesn't take that long, also because 
both members are on the same machine (and same controller), which is 
faster than going over the (10 Mb/s (since only one node has 100 Mb/s) 
LAN).)

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.)

Are the defalts generally OK, or is this a case like INIT/HEADERS where 
the default is really bad on a modern system? 

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.)