Update to Exabyte article I wrote in v7n46

[George Goble]

As far as reading back old tapes goes, I can still read back OK, tapes I
made in July 1987. Anything before that, is not compatible with the
current Exabyte format. Signal levels at the head preamp output (TP3,
right most test point on top of R/W card) are comparable to recently made
tapes (within 5-10%).

We have seen only 4 or 5 "bad" tapes (out of 300-400 tapes), Sony
P6-120MP, purchased from "consumer" wholesale houses.  The bad tapes had a
wrinkle in them and got hard write errors. One of them wrote ok, and
failed on read back, the wrinkle being eaten away by the rotary heads.
(another good reason to always read it back) I don't know of anybody who
had only 5 bad magtapes out of 6600-8800 1/2 inch reels.

In v7n46 I wrote: 
>Say, you have a tape with 3 tar files on it and want to save the first
>file, and you want to begin writing over the 2nd file.
>
>Normally you would "mt fsf 1; tar cf /dev/nrst0 .."
>
>for an Exabyte:
>
>"mt fsf 1; mt bsf 1; mt weof 1; tar cf /dev/nrst0 .."
>
>will work.  The regular filemark consists of an erased zone 3.8" long
>(needed to begin a write). In this case, the first filemark is
>rewritten in place, which creates an erased zone AFTER it, clearing the
>way to write more on the tape. The erase head is not helical.

[Above is true for Ciprico and our own (and some other) Sun 3.X drivers]

Warning:  The above sequences and in general positioning on a "stock"
(st.c) SunOS 4.0 and 4.0.1 device driver will not work (Ciprico rfsd.c
driver should work fine). st.c driver has no concept of "front" or "back"
sides of a filemark.  Only "safe" positioning operation for Exabyte (st.c)
on SunOS 4.0/4.0.1 is "mt fsf X" FROM THE BOT. Anything else will probably
abort or leave the tape positioned incorrectly (I saw a "mt bsf 1" rewind
the tape when 10 files out!)

It is also possible to write a "directory" on the front of a dump tape
(also works with most magtapes), AFTER the dump is done.  This way one can
store the command file which made the dump, along with the actual log of
the dumps on that tape.  Sometimes one will have some filesystems abort
(when dumped over a network) due to machines crashing and/or network
problems.  Most of the time, these can just be appended on the end of the
tape.  One initially writes a file of 10 Megabytes of zeros on the front
of the tape, then writes the dumps on.  One then rewinds, then uses a
slightly modified tar command to write on the directory. The mod to tar is
just to execute a "mtioctl REWIND" before exiting, so the device driver
close routine does not write a filemark after the directory.  If a
filemark were written, the tape would have two filemarks with the same
sequence number, which would confuse the Exabyte (will still work though).
You have room to tar on about 2 MB of whatever you want in the directory
area. To access the dump files, ones does a "mt fsf 1" to skip over the
directory and the blank area. One cannot "read" past the directory, as an
erased tape error (blank check) will occur.

The huge capacity of Exabyte also lessens dump hassles in other ways.  We
do level 0 dumps on large Gould systems every two weeks, and level 9s
everyday, no level 1-8s are needed, which makes restores a cinch.  These
are heavy use (lots of undergrads) machines, which have some filesystems
with 50% of their files touched after 2 weeks.  I put 4 Gould NP1s, 4
Gould PN9080s, and a CCI 6/32 on 5-1/2 Exabyte tapes, level 0.  The above
systems' level 9s all fit on 1/2 to 3/4 of one tape (dumped to a Sun 3/50
in my office) For Suns (staff and grad students only), and other research
machines, we have noticed the level 0s can be run every 4-6 weeks, with 9s
everyday.  Restores are simple, just do the level 0, and the most recent
level 9 tape.  Exabyte level 9s are highly resistant to "blowouts", where
some special research project or massive undergrad final projects, etc,
will touch 200 Megabytes or more in one day on a single filesystem.  A 200
meg blowout can wreak havoc with conventional backup schedules (requires
more tapes, keeping track of them, etc) An Exabyte sails along, taking
maybe 15 mins longer to dump the filesystem with the blowout, and it all
still fits on one tape.

I also have changes to the SunOS 4.0 SCSI tape driver (si.c, st.c) pretty
much done to make the Exabyte usable again. Mostly fixes file positioning
and not being able to read past EOF problems.  It has been tested only on
a 3/50 at this point.  Will post the diffs someplace if there is any
interest in it.

George Goble, Engineering Computer Network, Purdue U, W. Lafayette IN 47907 
(317) 494-3545  Arpa: ghg at purdue.edu  uucp: {backbone}!pur-ee!ghg