[Info-vax] HBMM

[Phillip Helbig---undress to reply]

In article <j7hff7$n55$1 at usenet01.boi.hp.com>, "Robert A. Brooks"
<rab at aitchpee.com> writes: 

> 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

OK.

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

OK, but then why the add 1024 stuff?  Just to make it available very 
early in the startup sequence, before such a command could normally be 
issued?

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

Yes.  Upgrade to 8.3 tentatively planned for Christmas.  I'm still not 
100% sure I'll do it, though, due to the lack of patch access for 
hobbyists.  Despite various people who are much better connected than I 
hinting that something might happen, nothing has.  I also haven't found 
a way to PAY for patch access.  (Whether I would depends on the price, 
but where can I even get a quote?)

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

Any reason not to go up to 1,000,000 with 7.3-2?

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

OK.

Thanks for the information!