[Info-vax] secondary page and swap files, MINICOPY, SYSHUTDWN.COM

[Kenneth Fairfield]

On Aug 7, 2:54 am, hel... at astro.multiCLOTHESvax.de (Phillip Helbig---
undress to reply) wrote:
> I set up some secondary page and swap files on a shadowed non-system
> disk.  After a reboot, I had a merge on this shadow set (and on no other
> shadow set).  Do I need to put something into SYSHUTDWN.COM to avoid
> this?

I believe this is normal/expected.  Any process still running when the
system halts could have pages mapped to a pagefile on that shadow
set, and therefore, a merge is required on reboot.  The only solution
is to be sure all processes (other than, like, the one running the
shutdown), are stopped so that pagefile disk can be dismounted
cleanly.

Unless your systems page heavily, you pretty much shouldn't
notice it...

> Now that I have only ALPHA nodes in the cluster, using MINICOPY is
> easier.  When I dismount a single shadow-set member with
> /POLICY=MINICOPY, then I get a MINICOPY when it comes back into the
> shadow set.  What is the point of MOUNT/POLICY=MINICOPY during the
> initial creation of the shadow set?  Would this provide MINICOPY
> functionality when a single member leaves and returns, even if it is not
> dismounted with /POLICY=MINICOPY?  Is there any reason not to specify
> /POLICY=MINICOPY at the initial creation of a shadow set?

Both HBMM and MINICOPY make use of memory-resident bitmaps.
I believe the motivation for setting minicopy on the mount is to be
sure that memory is available/allocated up front, rather than finding
you don't have it when you need it.

Seems to me the same question was asked here in the not too
distant past and somebody like Rob Brooks had a more definitive
answer.  You might try searching the archives.

> Is the problem regarding the merge mentioned in the first paragraph in
> any way related to MINICOPY?  IIRC, the shadow set was not initially
> created with /POLICY=MINICOPY.

No, unrelated.

> Would HBMM have helped with the problem regarding the merge?

No.  Well, depending upon your configuration...   HBMM helps
when you have a multi-node cluster, and the shadow set in
question remains mounted on at least one node with HBMM
enabled for that volume.  That node will execute the mini-merge
when the crashing/shutting-down node goes away.

Again, HBMM uses memory-resident bitmaps to accomplish
the merge (of only those blocks that may have changed).
A node (re-)booting by definition does not have those have
"memory" of those bitmaps, so it has no way to do a mini-
merge.   Ditto, actually, for mini-copy.

> Is it possible to turn on HBMM but not for the system disk (since I
> don't want DOSD)?

That sentence doesn't really make sense to me.  Again,
I think you have some context (your specific cluster
configuration) that has been spelled out, so vague/general
answers are all that I can give.

You *can* turn HBMM on for the system disk.  However,
it only makes sense if that disk (and all its members) is
also mounted on another node in the cluster.

This has nothing to with DOSD.  The only connection I
can guess is that DOSD requires a non-shadowed disk.

If I didn't say so above, please be aware that you can
(and should?) have both MINICOPY and HBMM turned
on for volumes that are mounted cluster-wide.  They are
totally compatible with each other, but of course, serve
different functions.

But HBMM only makes sense if both (all) members of
the shadow set remain mounted on the node that will
execute the merge when some other node (or cluster
"event") induces the  merge.  If you're shadowing MSCP
served disks from different nodes, so if a node shuts
down it takes a member with it, HBMM won't help
you.

    -Ken