Secondary Pagefile & VMS Shutdown

[Jefferson Humber]

Have a few servers with secondary pagefiles installed on non-system disk LUN's.

I have noticed that when the system is rebooted that these disks in question sometimes go into a mount verify (rebuild) on the way back up. I assume this is because they couldn't be dismounted cleanly !?!?

Should I do a MC SYSGEN DEINSTALL/PAGEFILE as part of the system specific shutdown ?

Does anybody else have these issues and overcome them ?

It's not a major problem, since I don't reboot them often..... but would be nice to get it a bit cleaner when I do.

Thanks in advance,

Jeff

[Uwe Zessin]

when a disk was not properly dismounted a REBUILD operation is done, but not a mount verification - at least I have never seen that behaviour.

A mount verification happens when there are problems on the communication path to the disk.

Another cause for MV is the OpenVMS host based volume shadowing software which (ab)uses this functionality to stall I/O operations during a change of shadow set state.

Are you using shadowing?

[John Eerenberg]

Amother reason for a mount verify is if the path is switched. In that case, MV is a normal part of path switching.

Does the path change at the time of the MV?

[Jefferson Humber]

Sorry about the Mount Verification statement, I meant rebuild... it's been a long time since I've rebooted one now.

Does a Deinstall seem logical ?

[John Gillings · Accepted solution]

Jeff,

>Does a Deinstall seem logical ?

Yes it's very logical, and sensible, BUT it's unlikely to actually do anything in practice :-(

The reason is the file won't actually be deinstalled and closed until all the active pages in it have been accounted for. If all the processes terminate before the disk is dismounted, you'll get a clean mount. On the other hand, if you DON'T deinstall you're guaranteed NOT to get a clean mount.

Page file deinstallation has improved greatly in the past few versions, but it's still not complete for every circumstance.

What's needed is a mechanism which makes each process with pages in that page file fault them back in. Even if they're immediately faulted back out, they will go to a different page file, because new allocations from the deallocation candidate are closed. As you say this isn't a "major problem", so it doesn't get much priority from engineering. There are also some nasty issues, like what if there isn't enough virtual address space remaining to take the load? (difficult or impossible to predict in advance, especially for marginal & pathological cases). The question is, is the benefit worth the engineering investement? Especially balanced against other things that could be fixed or improved.

To minimise the impact, try to put your page files on a volume by themselves. Any rebuild will then be so fast you won't notice it. You will also isolate your paging I/O from other I/O streams, which is worth doing for its own sake.

Also note that you'll have a similar issue with the disk containing your cluster environment files (SYSUAF, RIGHTSLIST, QMAN & friends) because you can't close them before the dismount. Same advice - put them on their own (small) volume, away from application data files.

This all gets MUCH easier with SANs as it becomes feasible to create virtual LUNs specificially for these kinds of purposes.

If it's the message or extra time during STARTUP that "offends" then you can mount your disks /NOREBUILD in STARTUP and run a batch job later to perform a SET VOL/REBUILD against each of your disks. This will be a noop if the rebuild isn't required (or you can /REBUILD=FORCE if you want - I think there's also a F$GETDVI item somewhere to let you find out if the disk needs a rebuild). This is quite safe, and should speed up your startup procedure. Worst case is some free blocks may be "quarrantined" from allocation and some quotas may be incorrect until the rebuild is done.

Oh, and just so you know, this also happens to your system disk for the same reasons, but you don't see the message!

[Ian Miller.]

I think the answer is adding MC SYSGEN DEINSTALL/PAGEFILE to your site specific shutdown MAY allow the disks to be cleanly dismounted and doesn't do any harm so add it but don't be surprised if the disks are still rebuilt on startup.

[John Eerenberg]

I agree with John. Putting the page/swap files on a separate disk is the way to go. I've never had any problems.

Doing a mount/norebuild is a good idea too. I've got a detached process that triggers a few minutes after each reboot to do set vol/rebuild as needed.

I highly recommend that you do a analize/disk/repair as needed as well.

Automating these at boot time has kept our volumes in good shape . . . (defragmenting and other tasks not withstanding).

john