Has anyone succeeded in doing multiple backups onto an Exabyte?

[Dave Olson]

In <625255CA893F60133A at KRDC.INT.Alcan.CA> ACCESS at krdc.int.alcan.ca (Shawn Allin - Alcan KRDC Computer Services) writes:

| Date sent:  18-JUL-1990 11:57:24
| 
|      Hello,
| 
| Has anyone managed to get multiple backups on an Exabyte as of yet?  We're
| using the unit sold by SGI.
| If it is possible, could you please send me the details?  (IRIX version,
| which program, etc).
| It seems REAL silly to have to use separate tapes for separate backups when
| you've got 2 gigabytes to play with...
| 

There is a bug that I introduced in the 3.2 release that shows up most
frequently with the Exabyte drive (as opposed to QIC drives), although
it has on rare occasions been observed (or claimed to have been seen)
on QIC drives as well.  The bug is that after doing an
mt feom (or the equivalent ioctl), and then the ioctl to determine the
block size to use, that the tape will sometimes get rewound to BOT
on the next write.  Needless to say, this trashes your existing archive.

The bug is fixed in 3.3.  In most cases, explicitly supplying the block
size to the backup program (bru and tar) prevents the second ioctl
from being called, and this circumvents the problem.  Unfortunately, if
it doesn't work for you, you lose an existing archive, so experiment with
a tape you don't care about.

Finally, there is yet another bug in 3.2 and in 3.3 that will be fixed
in a future release.  This bug happens when the first thing you do to the
tape after a boot (only if booted with a tape in the drive) is a sequence
like this:

	mt rew; mt feom; tar cvf /dev/nrtape ....

On the first write, the tape again rewinds to BOT, trashing your archive.
The work around is to insert an additional tape command, such as:

	mt rew; mt fsf 1; mt feom; tar cvf /dev/nrtape ....

Removing the tape and then re-inserting it before doing the backup should
also prevent the bug from occurring, but if you are using backup scripts,
it would be safer to add the mt fsf.

My apologies for these bugs.  Unfortunately, there are so many tape drives,
backup programs, and permutations of tape commands (AND system state)
that it becomes more and more difficult to try all the possible cases.
Of course, once found they go into the regression tests, but that doesn't
help the people who have to deal with them...
--

	Dave Olson

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