ghg@ea.ecn.purdue.edu (George Goble) (12/17/88)
This is an update to the article (7378@ea.ecn.purdue.edu) I posted
to comp.periphs on Exabyte drives on 12/13/88.
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.
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@purdue.edu uucp: {backbone}!pur-ee!ghg