benedict@chaos.utexas.edu (Thomas Benedict) (05/19/91)
Here's my problem: We have a tape that has multiple tar format archives written to it. The way we did this was to skip to the end of tape, and then write an archive. Simple 'nuff. The problem is that the mt utility in IRIX seems to have a little glitch. If you do an mt feom using /dev/nrtapens it will happily whirrrrr over to the end of tape, then happily rewind itself, then VERY happily tell you you are at the end of tape. So our intrepid researcher skipped to the end (beginning) of tape and wrote his new backup, handily overwriting the beginning of his tape. He didn't overwrite a whole lot. Maybe 20 meg tops. So there's still around 80 meg of good data on the tape... only it's past the end of tape marker. Does anyone know how to get past the end of tape marker on an SGI QIC tape drive? It's the standard SCSI Viper 150 tape that you get with your machine. Tom Benedict benedict@chaos.utexas.edu Center for Nonlinear Dynamics
olson@anchor.esd.sgi.com (Dave Olson) (05/20/91)
In <BENEDICT.91May18121817@chaos.utexas.edu> benedict@chaos.utexas.edu (Thomas Benedict) writes: | Here's my problem: | | We have a tape that has multiple tar format archives written to it. | The way we did this was to skip to the end of tape, and then write an | archive. Simple 'nuff. The problem is that the mt utility in IRIX | seems to have a little glitch. If you do an mt feom using | /dev/nrtapens it will happily whirrrrr over to the end of tape, then | happily rewind itself, then VERY happily tell you you are at the end | of tape. Are you absolutely, positively certain that you used nrtapens? There was a bug with this in 3.3 for Exabyte, but that was because the sequence has to be emulated on Exabyte, and I missed a state in a couple of sequences. I have NEVER heard of this on the QIC tapes (and believe me, if anyone had complained about it to SGI, I would have heard it about it through many channels!) | So our intrepid researcher skipped to the end (beginning) of tape and | wrote his new backup, handily overwriting the beginning of his tape. | He didn't overwrite a whole lot. Maybe 20 meg tops. So there's still | around 80 meg of good data on the tape... only it's past the end of | tape marker. Sorry, but you are out of luck. When writing from BOT, almost all QIC drives erase all tracks ahead of the write head while writing the first track (this includes the Archive drives that SGI sells). 150 Mb / 18 tracks is just over 8 Mb per track, so the whole tape was erased. I realize it isn't much consolation, but one thing you learn over time if you need your backups is to NEVER put more than one backup per tape, if it isn't readily re-creatable, since sooner or later you always make a mistake (or the vendor does in their software). True, this can waste a lot of tape, but if you need it and you overwrote it, you didn't save any money. If you have a reproducible (even if only occasionally reproducible) case that shows your problem, I'd be very interested in the details. Scatter 'mt stat' through your script, hinv, and ls -l on the devices will help in tracking down problems (yours or mine). This is a standing invitation for SCSI tape and disk problems. ** NOTE ** this is NOT a substitute for the TAC (Technical Assistance Center, formerly Hotline). I have my job, they have theirs, and mine isn't support. I make no promises about fixing problems, and I *NEVER, EVER* send patches, although I might suggest a work around. I WILL make an attempt to track down *REAL*, *REPRODUCIBLE* problems, but I do ask that if you have software support, start by using it; if not, consider buying it. I reserve the right to not reply immediately or even within a reasonable time, due to the unreasonable demands of my managers that I get my job done :) The TAC has a long list of common problems and errors, and they are more likely to spot and answer many of them than I am. They also need to know about the problem so that they can help the next person who sees it. -- Dave Olson Life would be so much easier if we could just look at the source code.