Use of RMS_SEQFILE_WBH and Backups

[Kevin Atchley]

I am looking at migrating data from one system to another and am trying to reduce the time of copying data as much as possible. I have made some changes in the BACKUP command and gained some improvement, but I want to reduce it more. While Googeling I ran across someone suggesting I make a change to set RMS_SEQFILE_WBH = 1 and then a SET RMS /BUFFER=10 /EXTEND=650000 /BLOCK=127. I did this on a test system with test data and was able to improve the trial times from 30min down to 5min.

Does anyone have any advice or experience about whether using this command can/will cause problems. During the data migration period both source and destination machine will not be used, so I should have unshared access to the data.

Thanks in advance,
-k

[Robert Gezelter]

Kevin,

Even without RMS_SEQFILE_WBH, I have been able to ensure maximum performance by upping the buffers, blocksize, and extendsize.

On many tests that I have done, the biggest improvement is by increasing the extendsize to the maximum.

A cautionary node: On some older releases of BACKUP (this posting does not specify the OS version), BACKUP ignores the RMS defaults. To get many of these advantages, it was necessary to write the output saveset using DECnet transparent file access (e.g., 0"username password"::xxx.BCK/SAVE_SET) to get the effect. While those versions of BACKUP did ignore the RMS parameters, FAL uses them.

Also be careful that the buffering does not run into other problems with the various quotas.

- Bob Gezelter, http://www.rlgsc.com

[Hein van den Heuvel]

>> While Googeling I ran across

I suspect you found:
http://h71000.www7.hp.com/faq/vmsfaq_011.html

But did you re-type?
Becase the max extend is 64K, not 650,000.

Anyway, that FAQ is a little misleading as RMS_SEQFILE_WBH has no effect on Backup.

There may be some version dependencies here, but Backup under 8.3 has WBH be default enabled and nothing for multiblock (MBC) nor multifuffer (MBF) thus accepting the SET RMS default.

You can test this with...
$SET PROC/PRIV=CMKRNL
$BACKUP *.* X.X/SAVE
^Y
$SPAWN
$ANALYZE/SYSTEM
SDA> SHOW PROC/CHAN ... notice channel for X.X
SDA> show proc/rms=(fab,rab,bdbsum,noifb:1)
:
Doublecheck channel in FAB : STV
See WHB in RAB : ROP and check MBC and MBF
See buffers in BDBSUM

The NOIFB:1 forces display for IFI = 1 without actually displaying the corresponding IFAB selected.
Here is the only file anyway.
SDA> ^Z
$ LO
$ DELETE X.X.

IMHO there is rapidly diminishing benefits after using more than 4 buffers, beyond 8 is it not measurable... for sequential access. In fact it could possibly confuse the storage subsystem in thinking it is presented with a random load instead of sequential write, and for other storage subsystem it may cause overload on a per-lun writeback cache.

I would also pick 124 or 112 for buffer size, notably for EVA targets, but that's me.

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

[Wim Van den Wyngaert]

/group=0 will improve performance at least 10%.

Wim

[Kevin Atchley]

For Clarification : (sorry, I should have put this in the first post)


Both systems are VMS 7.3-2. It is a system to system copy of data utilizing and NFS mount on the target system.

And Yes, I did re-type the command instead of cut/paste, and stick an extra 0 on the /EXTEND.

[Guenther Froehlin]

Is this a disk-to-disk file-by-file copy?

From a VMS ODS volume to an NFS file system?

Or, is there a BACKUP save set involved?

/Guenter

[Kevin Atchley]

It is a BACKUP style copy of files. We have machine A that mounts an NFS mount point that is being "hosted" by machine B. Machine A then does a BACKUP of the files from machine A to a saveset on machine B. We then expand those files out to their new homes.

[Kevin Atchley]

It does appear the setting the buffers and blocks without setting RMS_SEQFILE_WBH does help with backup/copies we are doing. Testing does show there were no ill-effects.


Thanks to all.