[comp.os.vms] CRCs in VMS Backup.

AWPSYS@RITVAX.BITNET (07/23/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

Note!!!!  As of the Spring 1987 DECUS symposium VMS development stated for
the record that they STILL did not recommend turning off CRC checking in
BACKUP.  The reason they gave is that even though the hardware CRC can
ensure that tape is properly written, magnetic tape media has a nasty way
of dropping bits over time and BACKUP may not know that it is reading BAD
data on restore or BACKUP will get a tape read error but may not be able to
apply correction.  This is VERY important to backup because CRC failure
triggers BACKUP group XOR recovery mechanism that allow backup to recover
from its redunancy group.  So if you are STILL going to trust the hardware
alone then I would suggest that save tape as well by specifying no
redundancy groups with the /GROUP=0 qualifier.

CRC computing becomes the  critical bottleneck on slow VAX systems (less
than a 780 in speed  or the MicroVAX systems where the CRC instruction is
emulated). On the faster CPUs, other factors become the critical bottleneck
in backup performance.

What I have found as MOST important in BACKUP performance is the structure
of a disk.   Disks with lots of small and fragmented files belonging to
many different users tend to perform very poorly in backup. BACKUP is
slowed down substantially by having to constantly seek between the index
file and the actual file data. Playing with backup qualifiers until you are
blue in the face will not affect BACKUP times on these drives.  The only
thing that can help here is a faster spindle or volume shadowing.  (As
an aside, the RABBIT-5 product (which we tested but did not buy) DOES
give you a big gain here by "looking ahead" and opening up many different
files at once and caching the file headers)

In conclusion, I feel that the suggestions made by the DEC professional are
of no use to sites running higher capacity VAX Cpus.  In a typical Cluster
environment backups are run at night when CPU cyles abound. Disabling CRCs
gains pratically nothing and puts older save sets at greater risk.


Andrew W. Potter
Rochester Institute of Technology