Operating System - OpenVMS
1752572 Members
4283 Online
108788 Solutions
New Discussion юеВ

volume shadowing disk with queue manager and pagefile

 
SOLVED
Go to solution
Markus Waldorf_1
Regular Advisor

volume shadowing disk with queue manager and pagefile

Hello,

I moved the queue manager data and page/swapfiles to another disk named disk$alphavar in order to free up space on the system disk. I use volume shadowing for disk$alphasys and disk$alphavar to be able to schedule online backups. The problem is that everytime the system restarts, a complete new merge of disk$alphavar takes place. There is an entry to dismount disk$alphavar in syshutdwn.com, but it does not seem to properly dismount the drive because the files are busy.

What should I do?

Best regards,
Markus
12 REPLIES 12
Robert Brooks_1
Honored Contributor
Solution

Re: volume shadowing disk with queue manager and pagefile

If you are on OpenVMS Alpha V7.3-2 or V8.2, you should consider the use of Host-Based Minimerge
(HBMM). HBMM ships as part of V8.2, or is available through the HBMM V2.0 patch kit or the V7.3-2 UPDATE V0300 kit.

HBMM will greatly reduce the time needed to merge; likely down to seconds, depending on the value choses for the bitmap reset threshold.

-- Rob (part of the team that developed HBMM)
David B Sneddon
Honored Contributor

Re: volume shadowing disk with queue manager and pagefile

Rob,

The problem being described relates to having a pagefile
(or other file that is open until the last moment)
on a shadowed disk. The file is open at shutdown and causes
a merge when you reboot.

Markus,

We have the same situation -- given that you don't
normally reboot all that often, is it causing a problem?
Depending on the use of the system, the merge should
happen fairly quickly anyway (but then I don't know
exactly how the system is used or setup)

Regards
Dave
Robert Brooks_1
Honored Contributor

Re: volume shadowing disk with queue manager and pagefile

David wrote (in part) . . .

"The file is open at shutdown and causes a merge when you reboot"
Yes, that's correct; a merge is inevitable in the situation that Markus described. HBMM seems like a reasonable way to reduce the duration of the merge.

"Depending on the use of the system, the merge should happen fairly quickly anyway"

Unless Markus is using HSJ controllers, the merge will NOT happen fairly quickly on a modern-sized disk. A full merge is just that -- a merge of every LBN on the disk (independent of the file system). While MSCP-speaking controllers do support a controller-based minimerge, Fibre Channel and SCSI controllers do not, hence the reason why HBMM was developed.
David B Sneddon
Honored Contributor

Re: volume shadowing disk with queue manager and pagefile

Rob,

How does HBMM work in the situation where a pagefile
is located on a shadowset, the system is shutdown and
rebooted?
I don't see how it can help, unless I have not
understood something.

Dave
Jan van den Ende
Honored Contributor

Re: volume shadowing disk with queue manager and pagefile

Well,

already back in 2000, in the VX Company sponsored big Dutch VMS event, I have been seriously discussing the issue with Andy G.
He was not aware of it, like me considerd it a bug, toke notes, and promised to look into it.
We all know how the IA64 issue took preference....
Maybe this is a goor trigger to try and give it some boost on the priority scale.

Engeneering, are you monitoring?

Jan
Don't rust yours pelled jacker to fine doll missed aches.
Ian Miller.
Honored Contributor

Re: volume shadowing disk with queue manager and pagefile

The way to get engineering priorities set is via product management. Email your favorite hp contact with a request to be passed on.
You may also wish to post the issue on
http://www.hpuseradvocacy.org/
and get people to vote
____________________
Purely Personal Opinion
Volker Halle
Honored Contributor

Re: volume shadowing disk with queue manager and pagefile

Dave,

HBMM uses Write Bitmaps (first implemented for Mini-Copy) to keep track of which blocks on a disk have been written to. If there is a need to merge a shadowset, only those blocks of the shadowset need to be merged, which have been written to recently. This will greatly reduce merge time for those disks, which are not supported by controller-based mini-merge (implemented through Write Log entries on HSC,HSJ,HSD).

Write Bitmaps for HBMM are regularily reset by making sure all WRITE IOs to all members are finished and then clearing the bitmap (to reduce merge time).

This is all described in Chapter 6 of the V8.2 New Features manual:

http://h71000.www7.hp.com/doc/82FINAL/6675/6675pro_007.html#minimerge_fc_h

This feature is also available on V7.3-2 with the HBMM kit installed.

Volker.
Volker Halle
Honored Contributor

Re: volume shadowing disk with queue manager and pagefile

Markus,

there is no need to enter DISMOUNT commands into SYSHUTDWN.COM. OpenVMS SYS$SYSTEM:SHUTDOWN.COM will automatically (try to) dismount all mounted disks. Disks with

- open files
- installed files
- devices spooled to them

cannot be dismounted, unless all those files are closed, de-installed or unspooled.

You can try to add a

SYSGEN> DEINSTALL DISK$ALPHAVAR:[dir]PAGEFILE.SYS/PAGEFILE

into SYSHUTDWN.COM. If no processes have pages assigned to that pagefile anymore, the pagefile could be closed and the disk could then be cleanly dismounted, preventing a merge during boot.

It's always tricky to try to prevent merges when dismounting a shadowset containing 'cluster-common' files, as you need to make sure, that ALL open files on such a disk need to be closed during shutdown.

I typically end up putting:

$ IF F$GETDVI(device,"TRANSCNT") .GT. 1
$ THEN
$ SHOW DEV/FILES 'device
$ ENDIF

into SYSHUTDWN.COM (or even SHUTDOWN.COM) to document open files during shutdown.

Volker.
Volker Halle
Honored Contributor

Re: volume shadowing disk with queue manager and pagefile

Markus,

if this is a standalone system, HBMM is not going to help, neither would controller-based mini-merge, as there are no 'remaining' cluster members, who could process the mini-merge.

Volker.