Thanks to all who replied.
The bottom line is ``He's dead Jim.''
I originally wrote:
>I have an exabyte tape that has a damaged first file. It is not a
>tar format tape. This file was written using 1k blocks and is of
>157680 blocks in length. The damage begins around block 850 and
>lasts until about block 3000. I can force the tape to skip through
>the bad section, however, after getting past the bad section, there
>appears to be an error flag set somewhere that prevents read from
>working.
>
>Suggestions?
>
>The setup is:
>
> Sun 4/40
> SunOS 4.1.2
> gcc 2.3.3
>
The clue to the final answer:
From: vanepp@sfu.ca
>>It has also been suggested that I try dd. However, the tape is
>>sufficently messed up that dd fails.
>
>How does dd fail? If you are getting "I/O error out of memory" try (if you
>haven't already)
>dd if=/dev/tape of=/diskfile bs=126b
>which will get you the max block size for an 8mm (dd defaults to something
>smaller).
> Otherwise you may be screwed. I have been told that an Exabyte will
>lose sync on an error and all data thereafter will be lost. For sure if a
>tape mark is written at BOT you are dead, the Exabyte won't read further.
>There was a suggestion made in one of the SGI groups that as a last resort
>(in the eof at the start case) you can start a write of the tape, and then
>quickly power the drive off. This writes over the begining tape mark, but the
>drive doesn't get to write a new one, sometimes you can then get the rest of
>the data off the tape. This is however very dangerous and you may lose all of
>the data, and thus should be an absolute last resort (just before you toss the
>tape in the garbage can!). Good luck!
>
I believe that the tape has been damaged in a manner (yet to be determined)
that the tape is loosing sync even when trying to skip over the bad blocks
using dd. (I suspect that sync is eventually regained but a hardware error
flag is already set so things are still hosed.) As the tape contains other
archived image data, I'll forgo the last resort solution mentioned above.
Below is a summary of the suggested solutions:
____________________________________________________________________________________
From: "M. Damerell" <uhah208@sun.rhbnc.ac.uk>
>
>I dont know if this will work but conceivably:
>
>Write a C program to use ioctl's to:
>
>advance to end-of-data
>backspace N blocks
>read(2) and hope for something useful.
>
>Sorry if you already tried this. Mark
>
good idea. However, when backspacing an exabyte the tape appears to count the
records as it rewinds to the beginning of the file and spaces forward to
the desired position ... (I seem to recall reading this in an admin manual
at one time.)
From: Bill Walker <bwalker@hns.com>
>
>
>how about dd with "conv=sync,noerror"?? used to work on
>vaxen with ultrix...
>
>bill.
>
>--
>Bill Walker Sr Sys Analyst Pencom Hughes Network Girlfriend
>who i am. what i do. employs me. puts me to work. busts my balls.
>
>(703)609-5313(c) (301)428-5500 x3353(w) (703)450-2456(h) bwalker@hns.com
>
From: Jim Davis <jdavis@cs.arizona.edu>
>
>Have you tried dd(1)? It's pretty good in getting at the 'raw' tape.
>You might try something like
>
>$ dd if=/dev/tape bs=1k skip=3000
>
>You might need the 'conv=sync' option too, to keep the device driver
>happy.
>--
>Jim Davis | "But pain? As a solution?"
>jdavis@cs.arizona.edu | -- Clarissa Darling
>
From: Subramanian <sbmn@hpuxsv6.cup.hp.com>
>
>Most flavors of Unix provide at least two interfaces to tape
>drive. One is the normal rewind on open (or close) and the other
>is the no-rewind (usually thro' device names that look like /dev/rmt
>and /dev/nrmt). I hope you are using the no-rewind (nrmt). Also you have
>not indicated what program you are using to read the tape. It is
>possible that the program intentionally does a rewind, in which case
>dd will help. Even dd will work only if you have positioned past
>the bad patch and are accessing using the nrmt interface.
>
>I must admit that I have not worked on a Sun machine ; but it
>is hard to believe that Sun does not support a no-rewind interface
>for tape drive.
>
>Subbu
>
Ya, I'm using the no-rewind driver.
>From sbmn@cup.hp.com (S.Subramanian(contr))
>I hope that the error is "forgotten" on a close. If that is the case,
>you can close the device after skipping over the bad blocks, re-open
>and read - operating all the while on the no-rewind device file (nrmt ?).
>
>Subbu
>
I've been using a routine I've written to access the tape. It looks like
the problem with closing and re-opening the file is that open() is
rewinding the tape to the beginning of the file (the man page claims
that the seek pointer is set to the beginning of the file when the
file is opened).
Unfortunately, the tape is in such a state that dd barfs when trying
to skip over the bad blocks. The only way I've been able to slog my
way through the bad spot is to use record skip ioctls.
I also tried to use 2 different file descriptors on the tape device
by opening it twice, doin
________________________________________________________________________
Craig A. Gullixson
Senior Research Associate INTERNET: craig@sunspot.noao.edu
National Solar Observatory/Sac. Peak PHONE: (505) 434-7065
Sunspot, NM 88349 USA
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:55 CDT