Exabyte 8mm tape drives come of age

[George Goble]

[[ This is a lengthy finrst-hand review of the Exabyte 8mm tape drive.  It
is getting its own issue because of its length.  At the SUG Conference,
people expressed interest in having the longer postings actually mailed
out rather than merely archived (provided they are of general interest).
So, this is a trial message to see what the reaction will be.  --wnl ]]

In April, 1987, we started driver development on the 2nd BETA Exabyte
drive on a Sun-2/120. Most of the initial headaches resulted from
deficiencies with the Sun-2 SCSI system. For a couple of months work
continued on the Sun-2, but was later moved to a Sun-3/50 (SunOS
3.2/3.3/3.4). The Sun-2 could not handle the disconnect, save-data-pointer
SCSI commands which Exabyte began to require in the summer of 1987.  Also,
the Sun-2 was just too slow to stream the drive while data-comparing each
byte.

Initially, the Sun-3/50 would run the drive, but not in disconnect mode,
since the Exabyte would disconnect on odd byte boundries sometimes, but
Exabyte finally added a vendor bit to force disconnects on even bytes
which then allowed full disconnect/reconnect operation on the 3/50.

Summer of '87 also uncovered a myriad of problems, broken tapes, nasty
jams, motor and brake problems, lots of "hang" conditions, which were all
nice to work out before the product was up for sale.  I was on the phone
several times/day with the person doing the drive firmware at this time.
I am very grateful to Exabyte to have allowed us to have BETA drives which
allowed us and a few others to uncover quite a few bugs before it hit the
market.

There were few remaining problems when the drive went up for sale in Sept
1987.  Most of the problems one would "expect" from an 8mm Camcorder drive
were not there.  Tape interchange problems (density was 35 million bits/sq
inch), tape "wearing out", being affected by weak magnetic fields, or not
being able to read it back after several months, just did not happen. The
early prototype drive "P4-6" didn't have firmware (June 87) to spin down
the rotary head when the drive was not active, so a human had to be
present during testing to unload the tape if the firmware hung, etc.  One
day, I got called away to fix a crashed system someplace, left the Exabyte
test running, and it of course hung, and left the head spinning with the
tape loaded... for 45-60 minutes!  To my amazement, the tape was not
visibly damaged, and the drive read the area of tape with no errors where
the head had been left spinning!

Both us and Exabyte tested several brands of tape, and both agreed that
the SONY tapes worked the best (we found FUJI a close second, TDK and
Maxell to be the worst). Exabyte's lab testing showed tapes would not even
begin to "degrade" until around 800-900 passes, but due to their super ECC
methods, they were usable well beyond 2000-3000 passes. I don't think
anyone puts near this many passes on their backup tapes.

We were never able to "wear out" a tape (few hundred passes on a short
piece of it).. We ran a drive for 24 hours/day for 2 1/2 months.  It held
up mechanically fine. It was only cleaned once and didn't need it.  This
"lifetime" test simulated approximately how long a head would last on a
conventional tape drive.  (you can almost buy a new Exabyte for the price
of replacing a head on a 1/2" drive)

The ECC is phenomenal.  Tape is written in "stripes" diagonally across the
tape. Each stripe contains eight 1024 byte sectors plus 400 bytes of ECC
(per sector) plus control and servo information.  The drive does full
read-after-write checking, and even a single bit error causes the affected
block to be rewritten later on the tape in a different relative position
in the stripe. All this is sorted out on readback.  ECC can correct a 263
byte burst error in a 1024 byte sector plus something like 80 one and two
bit errors in the same sector. Compare that to your disks!

The fall of 1987 brought the ramp up of production, and the advent of high
speed filemark positioning (10X read speed).  As with the ramp up of
almost any new product, some problems developed when components were
purchased in mass quantities.  As usual, we always ended up with drives
made from the "bad" batches. The most notable was the "3-1/2 week disease"
which started in drives built or upgraded starting Dec 1987.  Drives would
run, almost to the day, 3-1/2 weeks of power up time and then start doing
flakey things, especially having read problems.  One could see the head
preamp output on a scope fading in and out. This was finally "cured"
around May 1988; turned out to be capacitors "leaking" very slightly,
hosing up the delicate DC bias in the head preamp circuit.

A 6 week disease was then evident, which also caused "flakey" operation,
and the appearance of tape interchange problems.  It was tracked down to a
critical capacitor in the head Synch circuit slowly drifting in value,
causing the head synch to drift out of acceptable limits in 6-9 weeks. All
13 of our drives had both 3-1/2 and 6 week diseases (some went back 5 or 6
times).  Head synch problems were laid to rest for good during the last
week of June 1988 by switching to a very good grade capacitor.  There were
also scattered problems, like "mode" motor problems, and bad crystal
oscillators, but those were fairly rare here.

>From the last week in June, 1988, until the present, it has been smooth
sailing.  Only 1 drive out of 13 has failed since end of June (5 months!),
compared with 100% of the drives every 6-9 weeks before that.  The one
drive which failed just needed a realignment and died in the first couple
of days.  Maybe it got dropped in shipping.

If you have drives which were built or upgraded before 6/29/88, it would
be a very good idea to send them back to be upgraded.  If your drive does
not have a playing-card sized sticker on the top lid, it has probably been
built or upgraded before mid June '88 and should be upgraded.

We break almost everything we get here, and have appreciated the long
working relationship with Exabyte in turning the drive into a solid
product.  Currently we see about 1 unrecovered write error/month (for all
12 drives total).  We read back (essentially dd to /dev/null) all tapes
made.  There was one case (late Aug) where a tape was written ok and would
not read back (error at the load point). There was some problem synch'ing
up at the "load point" (firmware bug) and this tape was successfully read
using MX firmware 4$23 (now released). This only happened once.  Once
tapes have been written and read back once, there have been no read
failures since 6/29/88 (the head sync cap fix).  Also, we have only really
"lost" one tape. It was heated to between 110 and 115F in the summer heat
wave in an unairconditioned apartment (Spec is around 105F I think).

It was observed in pre July 88 drives that during the gradual failures, it
was possible to write a tape ok, and have it fail on the readback.  Theory
was that the read-after-write did indeed work, but that after a pause, the
drive servo became sloppy (due to something being sick already), and
smashed already written and verified data.  This has not been observed on
drives after July 88. Out of general paranoia, we still read back (dd to
/dev/null) EVERYTHING, for an unattended overnight dump, this takes no
more (human) time.

Around once every week or two a few drives running MX 4$22 firmware
(summer 1988), would just unload the tape for no apparent reason, and Unix
would take a "no cartridge loaded" error. This was caused by the servo
code being overly paranoid about motor ramp ups, etc. It would occasionly
"panic" and emergency unload the tape. Currently released firmware
MX-4$23/SV-B017 fixes this.

We have run around 200 tapes (approx 60 of them almost full) since July
1988. Bitwise each Exabyte tape is equivalent to 16 reels of 2400 ft 6250
BPI (long records) magtape. In actual practice, it is more like 22 or 23
reels (doing dumps) since filesystems are usually started on new reels and
Exabyte reclaims all that wasted space as well. We have put as many as 250
filesystems (incremental level 9) on a single tape. That takes around 10
hours (due to the network), now we use 3-4 drives and due 50-80
filesystems on each one.

The advertised capacity of 2.3GB is only obtainable if the drive is run in
streaming mode (must be fed at 15 MB/min) AND your driver knows how to
deal with the LEOT warning zone.  The LEOT is a "warning" that PEOT (real
end of tape) is "near".  230 MB still remain though on a 120 Min tape.
The drive issues a SCSI check condition (does partial xfer if in fixed
mode) and the transfer must be restarted by the device driver.  4$23
firmware issues a check on every write after the LEOT.  The drivers from
Perfect Byte (Sun3.4), Ciprico, and possibly Artecon, are the only ones I
know of which handle the LEOT (4$22 or earlier) and let you use the last
230 MB on the tape. It is a real pain to make that work correctly. (Let me
know if any other drivers exist that can deal with the LEOT).  Most
drivers just return hard error when hitting the LEOT. Running the drive
start/stop (like dump via a network) results in the loss of 200-300MB or
so more.  4$23 firmware allows the driver to set the "pad stripes" to be
zero (right 3 bits set to 0 of the 2nd vendor uniq byte on a mode select
command). This reduces the nonstreaming loss to around 100MB. Most Unix
users are probably ending up with a driver which is run non-streaming, and
can't handle the LEOT, so they should figure on a capacity of 1.8GB
instead of 2.3GB. Anything which uses lots of filemarks (VMS, ANSI
formats, etc) loses severely!  A filemark consumes 2.2MB of tape (you can
put an entire DEC "RK05" disk image inside one Exabyte filemark, for you
oldtimers)

This summer, Exabyte added a "short" filemark (set "vendor unique" byte 5,
bit 7 in the Sun cdb (vu_57) to get a short mark).  The short filemark
only consumes .86" (.488MB) of tape (60 tracks) vs 3.8" (2.2MB) of tape
(270 tracks) for a regular filemark.  The short filemark cannot be
overwritten like the regular one can.  Comments in the next paragraph only
apply to "regular", not short filemarks. Some companies selling devices
and drivers to deal with the VMS world force (or default to) short
filemarks.

Due to the helical scan and the erase mechanism, there is a writing
limitation on Exabyte drives. "tar r" will not work ("tar c" is ok).  One
can only start writing at  1) beginning of tape, 2) on the end of what was
last written, 3) "front" side of a (regular) filemark. 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.

One can position a tape to the end of what was last written by reading
until a "blank tape" error is returned. Writing can be started at this
point. The tape does not become positioned somewhere down the "erased"
area as does a conventional magtape.  One can issue multiple reads at the
"blank tape" error, but the Exabyte stays positioned at the beginning of
the blank area, ready to accept write commands. File skip operations do
not stop at blank tape and will run into old data or run to the end of the
tape, so you have to be careful not to "mt fsf toomany".

The initial driver developmemt under SunOS 3.[234] ran the drive in
"fixed" mode like the Sun carts. Fixed mode looks like a disk; one can use
any blocking factor for writing and reading (even a different one for
reading). SunOS4.0 came out and made the default to be "variable" mode,
which looks like a 1/2" magtape. In general fixed and variable mode tapes
are not interchangable, hence all the grief caused earlier this summer.
In variable mode, the size in bytes of the write is remembered on the
tape, and must be read back into the same size (or bigger) buffer. Reading
into too small a buffer, will cause loss of data, unlike fixed mode
(buffer size assumed to be 1024 or a multiple thereof). In July 88, we
defaulted everything to variable mode, to stay compatible with Sun.

A number of people have called me on how to read Exabyte tapes made under
SunOS 3.[234] under SunOS4.X. If the tape was written in 1024-byte "fixed"
mode (the orig blocking factor does not make any difference) as on most
3.[234] systems, one can try a

	/etc/restore ifb /dev/nrst0 2

on SunOS4.0.  If you use 4.3BSD dump/restore like we do, use "1" instead
for the block factor (1024 bytes). It will run VERY slow!

Lastly, a final word of warning, this being from a design limitation of
Unix itself, one cannot read/write a single file > 2.0GB.  The Unix file
table offset overflows (it is a 32 bit signed quantity).  If you raw
read/write the Exabyte tape, you will run into this.  Doing a periodic
"lseek(fd, 0, 0)" will reset the file offset but do nothing to the drive
to allow > 2.0GB in a single file on raw tape.

We have also spent the last year and a half also shaking down an STC 2925
1/2" magtape (on Gould NP1s & Suns). We started with a "production" model,
which had been shipping for sometime.  Finding numerous bugs, having STC
out here several times, and running thru approx 40 versions (ROM sets) of
the drive firmware, we are now just getting that drive solid as well.  We
are still seeing a hard write error every 20-30 reels on magtape (this
translates into a hard write error once/tape on an Exabyte for dumps).
Exabyte is currently doing MUCH better than that.  (one hard write error
every 40 tapes or so; equiv to 800 magtapes) We also have not cleaned any
drives in 5 months!  (they got cleaned every month at Exabyte before that
due to failures).  Exabyte will be introducing a "wet" (Freon-TF) type of
cleaning cart shortly, similar to a Geneva. They will also probably
recommend a cleaning for every 30 hours' (once/week) use. Experience has
shown, that drives run fine for 100-300 hours between cleanings if kept in
clean office/computer room environments. Some people will probably put
them in steel mills, hence the 30 hour recommendation.  We have some
drives at 300 hours now, running fine.

One has to lie slightly to make dump give good tape estimates on the
length of the tape. Telling the real numbers to dump causes an integer
overflow during tape length calculation.  In reality, the tape is 348 ft
at 550700 "bpi". 550700 bpi is not really a true density, but is the
"effective" bpi assuming the Exabyte was a 9-track drive for purposes of
calculating dump tape capacity for dump(8).  Aerial recording density is
around 35 million bits per square inch. You get around 500kbytes per inch
of tape.

Thus:

/etc/dump 0fubsd /dev/nrst0 50 348 550700 /filesystem

Should work in theory, but will probably cause an overflow during tape
length calculations, so

We use:

/etc/dump 0fubsd /dev/nrst0 50 6000 54000 /filesystem

We use 4.3BSD dump on suns, so you will probably have to change the
blocking factor "50" (51200 bytes) to be "100" since Sun uses 512 byte
blocks. A fake tape length of 6000 feet and a "bpi" of 54000 seems to give
good estimates on sizing the cartridge.  These numbers are based on
experience and don't match exactly what you would get doing the math
(maybe the lack of gaps?).  Dumping a 230 MB filesystem yields an estimate
of "0.10 tapes".

Exabyte only builds drives, not complete subsystems. Various VARs and OEMs
buy their drives, add enclosures, write documentation, and put together
complete systems for Suns and other machines.  They also provide user
support.  Some of these companies are Perfect Byte, Delta Microsystems,
Artecon, Emerald, Spectrum, Megatape, etc.  The trade rags are full of
them.

Exabyte is rumored to be working on a drive which is 5GB, and transfers at
30 MB/min (twice the current 15MB/min), and will be able to read/write
your old tapes. Beta drive in about a year or so.  Also rumored is
development of an "X-Y stack loader". The "CHS" (Cartridge Handling
System) is purported to fit in a 19" rack, hold 5 drives, and 120 (small
model) and 240 (large model) tapes.  A robot arm will pick, insert the
tape, and close the door of the drive.

The current drive, the EXB-8200, reads/writes 14-15MB/min (around
240KB/sec), therefore it takes 2 hours 40 mins to read/write the entire
tape.  Dumps approach this speed when going from a local disk (restores
are horrible no matter how or from what they are done from due to
directory, indirect block, and inode synchronous writes). A Sun-3/50 can
stream 3 drives at once on its SCSI; we have had 7 drives on it at once
(you have to change driver slightly to move bits in minor dev).  All 7
drives will "run", although not at full speed due to the SCSI running out
of time. The Sun-3/180 with a Ciprico RF-3500 was found to also run 7
drives ok, and can stream 4 of them, and almost stream 5.  Skipping to
filemarks (both forward and reverse) runs at 10X the read speed (~150
MB/min), or about 16 mins to go the whole length of the tape. Rewind is
around 70X read speed or 2 mins 35 sec. Possibilities have been discussed
about having the next drive be able to position to any file, any block at
nearly rewind speed (3-4 mins), but nothing is committed. I may do some
experimenting with high speed positioning on the current drive via servo
commands issued from the 9600 baud "maint" port on the drive.

Until now, most of the work was done on Sun-3/50s running SunOS 3.4.
3/60's have also been run and seem to work ok.  A Ciprico RF-3500
controller is running on a 3/180 (that driver was rewritten also, and
given back to Ciprico). The next project is to make the SunOS 4.0 driver
"work" with the Exabyte.  It currently moves the tape, but still has a way
to go.

To conclude, it looks like the Exabyte drive is finally a solid product.
It comes just in time as systems with 1.2GB disks are becoming the
commonplace. I wish to thank Exabyte and all their staff for putting up
with a year and a half of continuous questions, bug reports, and bitching
from me. Also I like to thank Exabyte and Perfect Byte for donating some
drives (and Ciprico controller) to make all this possible.

--ghg

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