Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!think!ames!oliveb!felix!chuck
From: chuck@felix.UUCP (Chuck Vertrees)
Newsgroups: comp.sys.dec
Subject: Re: halve BACKUP times easily
Message-ID: <3427@felix.UUCP>
Date: Fri, 10-Jul-87 13:41:09 EDT
Article-I.D.: felix.3427
Posted: Fri Jul 10 13:41:09 1987
Date-Received: Sun, 12-Jul-87 16:01:23 EDT
References: <51700001@uicsrd>
Sender: daemon@felix.UUCP
Reply-To: chuck@felix.UUCP (Chuck Vertrees)
Organization: FileNet Corp., Costa Mesa, CA
Lines: 41
Summary: but there are consequences...

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.