Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!sgi!shinobu!odin!anchor!olson
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: Questions bru-ing
Message-ID: <1990Dec22.204946.28873@odin.corp.sgi.com>
Date: 22 Dec 90 20:49:46 GMT
References: <9012220452.AA17500@karron.med.nyu.edu>
Sender: news@odin.corp.sgi.com (Net News)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Lines: 71

In <9012220452.AA17500@karron.med.nyu.edu> Dan Karron@UCBVAX.BERKELEY.EDU writes:

| Dave Olson write about what Peter S. Shenkin writes:
| >in /etc/brutab.  There is absolutely no way to determine tape lengths
|                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^HUH???
| >ahead of time, since e.g. a QIC 150 drive could have either QIC150 or
| >QIC120 cartridges, in any of several lengths.  This is true of most
| >types of tape drives.

I guess this wasn't clear enough. What I meant is that there is no
way (in general) to tell what size tape is in a drive.  For some tape
drives, such as the Archive 2150S, one can tell whether a QIC120 or
QIC150 cartridge is present (~ 120 vs 150 Mb), but not if there is a 250 Mb
cartridge.  Similarly for 9 track (5 different common lengths), and
8mm (4 common different lengths).

Certainly a PROGRAM could tell ahead of time (at least for the first
volume), but there is rarely a reason to do so, since the program can
get a reliable end of tape indication when actual EOT is reached, and
then continue on the next tape (with the exception of the ts driver due
to firmware bugs).  See below also.
...
| Sounds like a good idea, actually. Since my tape backup is done automatically
| from crontab in the dead of night after I leave, I don't really care how
| slow it is. I mt ret the tape a number of time during the backup process
| just for its good health. My main worry is the tape filling up and the
| Night Backup script not knowing what to do. I compress the data to put off
| the eventual EOT . I would like some foolproof
| way to know in advance if I am goint to hit EOT, not blunder on it and
| risk corrupting my backup. That way I can do something intelligent before
| it happens!

I'm not that it matters too much.  Since the cron script can only use the
one tape cartridge, the best you can do is to backup one tapes worth.
bru (or tar, or cpio) will then ask for the next tape.  Since there
is no controlling tty, the prompt will fail and the backup aborts.
You still have the first tapes worth of backup.  If you have multiple
drives it would be useful to have a way to specify to bru that it
should switch to a subsequent drive without reading from /dev/tty,
but that is about all one could do.  It might be nice if bru would
checkpoint so that the rest of the backup could be continued later,
but one runs into potential problems of the filesystem structure
changing in between the two runs.

Certainly hitting EOT during the backup isn't going to corrupt
your backup.  It sounds as though you are doing multiple bru's
with the norewind device.  As long as you are doing an mt feom
in between each (or not repositioning the tape at all between
backups), there should be no problem; attempts to write
after hitting EOT will simply fail.  (NOTE: as previously posted
in this group, there was a bug that hit 8mm drives that occasionally
caused them to position incorrectly with multiple tape files in 3.2;
this was fixed in 3.3; however this bug had nothing to do with
hitting EOT.))

| We need a program to size any serial media (qic,dat, etc). I have seen it
| on more business oriented computer systems (NCR unix). We also need
| a taylored bru tab that know about sgi boxes (there are no entries for
| sgi tape devices in the bru tab!) 

Sizing any ONE tape before starting a backup is easy programmatically,
sizing all of the volumes of a multi-volume backup in the order they
will be used is unreliable due to the human element; the same problem
exists with a jukebox, but at least the order of the tapes is
unlikely to change in that case.  The SGI tape devices ARE in the
brutab, see my earlier postings.
--

	Dave Olson

Life would be so much easier if we could just look at the source code.