ACCESS@krdc.int.alcan.ca (Shawn Allin - Alcan KRDC Computer Services) (07/18/90)
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...
Thanks in advance,
Shawn Allin
Alcan International Ltd.,
P.O. Box 8400,
Kingston, Ont.,
Canada K7L 5L9
(613) 541-2178
ACCESS@KRDC.INT.Alcan.CA
Bitnet: ACCESS@ALCANKTN
Shawn Allin
Alcan International Ltd.,
P.O. Box 8400,
Kingston, Ont.,
Canada K7L 5L9
(613) 541-2178
ACCESS@KRDC.INT.Alcan.CA
Bitnet: ACCESS@ALCANKTNolson@anchor.esd.sgi.com (Dave Olson) (07/20/90)
In <625255CA893F60133A@KRDC.INT.Alcan.CA> ACCESS@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.