kai@uicsrd.UUCP (07/07/87)
There was a item in this months DEC Professional Magazine that should be of
interest to VMS system managers and operators.
Using the following VMS/BACKUP switches can HALVE your cpu and elapsed time.
I tried this on a one of my VAX 750's Massbus disks (approx. 65 Mb) to a CDC
92185 tape drive at 6250 bpi, and cut the full disk backup elapsed time from
35 minutes to 17 minutes (on an unloaded system) and cputime used from 10
minutes to 5 minutes.
BACKUP/IMAGE/NOCRC/BUFFERS:5/BLOCKSIZE:16384 dra2: msa0:dra2.bck
The idea behind this is that BACKUP was written a long time ago, when 6250
bpi tape drives were non-existent or very expensive. 1600 bpi tape drives do
not have the hardware built in for performing CRC checking of the data,
however 6250 bpi tape drives DO. So why have your VAX waste it's time doing
double CRC checking?
The /BUFFERS and /BLOCKSIZE switches help, and should probably be used even
if you don't want to trust the /NOCRC switch.
I compared this to our Raxco Rabbit-5 fast backup program (which I normally
use), and Rabbit-5 took 15 minutes to backup the same disk. Hardly worth the
$4000 price tag just to have a barely functional tape library manager (and
vaporware file locator).
Patrick Wolfe internet: pwolfe@kai.com
Kuck & Associates, Inc. uucp: {seismo,ihnp4,uiucuxc}!kailand!pwolfe
1808 Woodfield Dr. bitnet: pwolfe%kailand@uiucuxc
Savoy, IL 61874 csnet: pwolfe%kailand%uxc@uiuc.csnetchuck@felix.UUCP (Chuck Vertrees) (07/10/87)
In article <51700001@uicsrd> kai@uicsrd.CSRD.UIUC.EDU writes: >Using the following VMS/BACKUP switches can HALVE your cpu and elapsed time. >I tried this on a one of my VAX 750's Massbus disks (approx. 65 Mb) to a CDC >92185 tape drive at 6250 bpi, and cut the full disk backup elapsed time from >35 minutes to 17 minutes (on an unloaded system) and cputime used from 10 >minutes to 5 minutes. > BACKUP/IMAGE/NOCRC/BUFFERS:5/BLOCKSIZE:16384 dra2: msa0:dra2.bck >The idea behind this is that BACKUP was written a long time ago, when 6250 >bpi tape drives were non-existent or very expensive. 1600 bpi tape drives do >not have the hardware built in for performing CRC checking of the data, >however 6250 bpi tape drives DO. So why have your VAX waste it's time doing >double CRC checking? These twiddles of the qualifiers come up every so often, and are usually not accompanied by the consequences of each modification. I am remembering this from the response to a question/answer at a DECUS several years ago, so I may not have it totally right. The major problem is created by the use of /BUFFERS and /BLOCKSIZE. When BACKUP is writing a saveset and EOT is detected, it must write all current buffers before it unloads the tape. By specifying a 16k block size (default is 8k), and 5 buffers (I think the default is 3) you have increased the amount of data that must be written before the tape runs out from 24k to 80k. While this may not be a problem at 6250 bpi, it could be one at 1600 bpi. If the tape run out, the saveset is not complete, you will get a fatal error and can not continue. As far as using /NOCRC, I cannot comment on the long term consequences here. While GCR tape drives are inherently more reliable than 1600 bpi, being able to detect (and correct to a certain extent) a much larger class of errors, I don't know how not having BACKUP calculate crc's effects its overall capability to give back what you intrust to it. I do know that after using BACKUP for over 5 years, with in some cases some questionable tapes, and with defaults for crc and buffers, I was always able to "get it back." While faster is usually nicer, I never found the speed of BACKUP to be an overriding concern. I managed about 3 1/2 gigabytes, and with properly designed backup procedures, never spent more than about 30 minutes a day on incremental backups. Weekly backups which covered everything modified in the last week took a little over an hour. Once a month we captured everything with /IMAGE, which is the only place time was an issue. We could spend 10 to 12 hours on this. But this is also where I wanted every assurance I could get that "I could get it back." The time involved was not an issue.