Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!rice!sun-spots-request
From: canon!laukee@nsfnet-relay.ac.uk (David Lau-Kee)
Newsgroups: comp.sys.sun
Subject: Re: Using DUMP on Exabyte on Sun 3/280
Keywords: Miscellaneous
Message-ID: <4943@brazos.Rice.edu>
Date: 12 Feb 90 11:42:17 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 97
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v9n20, Replies: v9n38
X-Sun-Spots-Digest: Volume 9, Issue 40, message 6

>From:    merlyn@iwarp.intel.com (Randal Schwartz)
>
>In article <4618@brazos.Rice.edu>, heiser@sud509 writes:
>| This message is addressed to anyone who uses an Exabyte on a Sun 3/280
>| (SunOS4.0.3).  What parameters have you found to work best (for correctly
>| determining tape length, blocking factor for quickest operation, etc) for
>| backing up to the Exabyte using 'dump'?
>| 
>| Thanks in advance!
>
>Here it is, stolen directly out of a handful of Perl scripts that I use to
>back up 16GB of disk in 146 filesystems across 30 machines to any one of
>13 Exabyte drives...
>
>dump ${level}dsbf 43000 12000 64 - $device | dd of=/dev/nrst1 obs=64b
>
>where $level is like "0u", and $device is the device to be dumped, like
>"/dev/xd2c".  The "dd" command is possibly on a different system via rsh,
>which is why I have the pipe and dd.
>
>I don't know where I got the numbers... I think the local rep gave them to
>me.  Also, I have found 64 to be a reasonable compromise between speed and
>running out of buffers on one of our heavily used machines.
>

Drawing from the Sun enhanced SCSI manual:

The Exabyte organises its data as tracks of 8192 bytes.  For a 90 minute
tape (cartridge type 2048, e.g., Canon P5-90), the tape is 340 feet long.
For a 346 foot tape (4152") there are 261660 tracks of 8192 bytes, (i.e.,
261660 / 4152 tpi = 63 tpi = (63 * 8192 = 516096)*8 = 4128768 bpi).

To allow for defects you should assume a density of 4100000.  *If* you are
using dump to write the tape (not dd) then you should correct the tape
size by increasing by 840/blocksize to account for the fact that dump
assumes a larger interblock gap than the exabyte leaves.

Since the exabyte organises data in tracks of 8192 bytes (and any
unwritten data in a track is wasted space) maximum utilisation occurs when
the blocking factor is a multiple of 8192 bytes.  Now under 4.0 (and I
guess 3.X) the maximum size of a data transfer over the SCSI bus is 63k
bytes (viz 126 blocking factor you'll often see with tar).  For maximum
throughput and minimum waste Sun recommend a blocking factor which results
in the nearest multiple of 8192 to 63k bytes, i.e., 56k bytes,  therefore:

use tar b 112
use dump b 56
use dd bs 56k

So for a straight dump onto a SCSI'd exabyte you'd want:

dump 0ucbsdf 56 5190 4100000 <exabyte raw device> <file system>

I don't know about the 64b = 32k blocking factor suggested previously for
dumping to a pipe, but it is certainly reasonable for getting to the
exabyte (since it is a full mutiple of 8192), however it does look like
32k is well below the 63k SCSI bus transfer maximum.

There are probably good reasons for wanting to pipe into an rsh to dd onto
the exabyte, but for dumping across a network I usually go for specifying a
remote tape unit to dump.

Something like this should work as a general exabyte dump script to be rsh'd
on various machines on your network:

#!/bin/sh
PATH=:/bin:/usr/bin:/etc
IFS=

default=9
ebhost= <default exabyte host>
level=${1-$default}
machine=`/bin/hostname`
tapehost=${2-ebhost}

if [ "$tapehost" = "$machine" ]; then
        prefix=""
else
        prefix="${tapehost}:"
fi      
echo "Making a level $level dump for $machine onto exabyte on $tapehost"
for i in h g a; do
        echo "dumping sd0$i" 
        /etc/dump ${level}ucfbsd ${prefix}/dev/nrst2 56 5190 4100000 /dev/rsd0$i
        sleep 120
done
echo "Level $level dumps for $machine finished."

Note the 120 second sleeps between filesystem dumps.  This is because the
exabyte pauses for several seconds after a filemark has been written.  The
Sun driver has a pause built in to prevent operation during this period,
but in my experience this has proved insufficient.  I don't know whether
the beast needs to "cool down" before starting a second dump file, but
since I do them overnight I'm not worried as long as it works.  Also note
that multi tape dumps will not work since I am not recalculating tape
remaining between files (but with 2.04 Gig and only 7 machines I'm not too
bothered!).