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

[Phillip Helbig---undress to reply]

In article
<7ce77c2e-0418-4b40-b89e-6226cc1ead0a at a2g2000prf.googlegroups.com>,
Kenneth Fairfield <ken.fairfield at gmail.com> writes: 

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

I have many files such as SYSUAF.DAT etc on a non-system-disk shadowset.
I had similar problems there, but took steps to make sure nothing still 
had those files open.  I'm pretty sure there is no application which has 
the files open, but rather the "system itself".

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

No, no heavy paging.  I suspect that the merge will take place whether 
or not the file is actually used.

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

Is there a DISADVANTAGE to specifying it at MOUNT?  I'm thinking the 
bitmap might log all writes until the member is mounted again, whereas 
specifying it at DISMOUNT will log only those after the dismounting 
takes place.

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

OK.  So, if there is a disk which is mounted only on the system which 
reboots at the time of the reboot, then HBMM isn't available.  Makes 
sense.  But if for some reason a merge is unavoidable, then keeping it 
mounted on another node might allow HBMM.

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

Right.  Add 4096 to SHADOW_SYS_DISK.

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

Right:

$  mc sysman help sys_Parameters dumpstyle

       If you plan to enable the Volume Shadowing minimerge feature on
       an Alpha system disk, be sure to specify DOSD to an alternate
       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.

Right.

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

My setup is locally connected SCSI disks, all with a direct connection 
to only one node.  Every disk is a shadowset.  System and page/swap
disks have both members on the same node.  Other disks have members on 
different nodes.

For PLANNED reboots etc, everything works OK.  If one member goes down 
with a node, at worst I get a quick minicopy.

For unplanned reboots, I expect merges.  Since I haven't added 4096 to 
SHADOW_SYS_DISK, I can't expect minimerge on system disks.  OK.  What 
about other disks.  Do I need to "turn it on" somehow, or is it there 
automatically?  Still at 7.3-2.