Sorry for the repost if you've already seen this. I posted it last week
but I haven't seen it come through so I'm trying again.
I asked:
> From: todd@flex.Eng.McMaster.CA (Todd Pfaff)
> Subject: how to skip past tape EOM?
>
> Help!
>
> I have an Exabyte 8500 format tape written under SunOS 4.1.2 which
> was inadvertently rewound before writing a file which was supposed
> to go at the end of the tape. Therefore, the first file (at least)
> has been overwritten, but I'd like to recover the other files if
> possible. Is there someway to skip to the beginning of the first
> file after the end-of-media mark?
I got several helpful responses and one of the suggestions worked.
I'm now in the process of recovering some dump files which I thought
were history.
A bit more detail about what was on my tape: there were a large number
of dump files written one after the other on the tape, and then the
offending dump file written at the beginning of the tape which was
obscuring access to the other dump files because an End-Of-Media mark
is placed after the last file written to tape. I don't know of any
way to tell the driver to skip past the EOM mark (after writing this
I got a response from Perry_Hutchison.Portland@xerox.com which indicates
that I may have been able to skip the EOM using mt and dd, but I didn't
try it so I don't know if it works).
Here's what I did:
1) Rewind the tape.
mt -f /dev/rst1 rew
2) Skip to the EOM mark (and don't rewind :-).
mt -f /dev/nrst1 eom
3) Create a large file to write to tape. I don't know how much
data has to be written to wipe out the EOM mark.
mkfile 10m junk
4) Start writing this file to tape, but interrupt the write without
closing the file such that an EOM mark will not be written.
I let the write proceed for about 5 to 10 seconds and then switched
off the power to the tape drive. This method works with an external
Exabyte drive which has an accessible power switch; I don't know how
to apply it to an internal drive.
tar cvf /dev/nrst1 junk
< wait a few seconds and then power cycle the tape drive >
5) Rewind the tape and skip to the desired file.
mt -f /dev/rst1 rew
mt -f /dev/nrst1 fsf N
Actually, I found that this last command would return
an IO error for N > 1 and then the driver would think
the drive was offline or the tape was unloaded when
in fact it was not. The following sequence was
necessary to skip to file N (anybody know why?):
mt -f /dev/rst1 rew
mt -f /dev/nrst1 fsf 1
mt -f /dev/nrst1 status
mt -f /dev/nrst1 fsf N-1
Thanks for all the responses.
------------------------------------------------------------
From: blymn@awadi.com.AU (Brett Lymn - System Admin)
A (brutal) solution I have heard is to start the tape drive writing to
the tape and then turn the tape drive off, the idea being to overwrite
the eom marker and not let the drive write a new one.
-- Brett Lymn Computer Systems Administrator AWA Defence Industries------------------------------------------------------------ From: David Fetrow <fetrow@biostat.washington.edu>
Past End-of-File is easy enough (use mt). Is that you want?
-- -dave fetrow@biostat.washington.edu
------------------------------------------------------------ From: Russell Ruby <russ@MATH.ORST.EDU>
I had a somewhat similar situation a couple of months ago... i accidentally had recycled all the baseline backup tapes containing a file system of a "dead" disk. After checking backup records, i figured two of the overwritten tapes in fact had the data i wanted somewhere past the a newly rewritten end of information, or end of media "eom" as it is called... Using the following described process (for an exabyte 8200) i was able to recover the 400 megabytes of missing info -- what a relief...
(by the way, a number of suggestions from well-intentioned knowledgeable people involved splicing the tape -- i was a bit chicken to try that approach and was glad this other approach got the job done)
--- included message --- To: arrent!angel@uu.psi.com (A.R. Rivera) Subject: Re: HELP: Getting data from mag tape In-reply-to: Your message of Tue, 23 Jun 92 10:12:12 -0700. <9206231712.AA00083@Arrent.COM> Date: Thu, 25 Jun 92 14:03:20 PDT From: Russell Ruby <russ@intihuasi.MATH.ORST.EDU>
Assuming that what you meant was that you want to get past the "end" of the tape, here is something that works for EXABYTES, and probably works for other tape devices as well...
assuming the Sun device driver 1) first go to the end of media mt ... eom 2) Start copying a large file to the device, but as soon as it writes enough to get past whatever gibberish is involved in the end of information, double file marks and perhaps blank space (... whatever), "interrupt" the writing
[i remember making an estimate based on information in the 8200 hardware manual which came with our drive (and other info), also, i had lots of room before the file i wanted, so i wrote about 10-15 megabytes before interrupting the write...] process by either i) more civilized approach, if information is coming in across the network, break the ethernet connection so that the drive stops writing and waits for data, and then turn the drive off, or ii) less civilized, just turn the drive off. hint: using tar cvf with an a directory full of files of fixed size gives an easy way to judge how much has been written before you "interrupt" the write. you could always write a program too which writes and sleeps (don't close the file - otherwise i think you will get another eom). 3) turn the drive back on, should rewind, or else do "mt ... rewind" 4) use "mt ... fsf #" to skip over whatever boring old information might have existed at the beginning of the tape. With the exabyte, even though i was skipping forward one file at a time, somewhat surprisingly, it appeared to skip over the eof at the end of the "spliced" file, stopping at the eof of the next file and so i needed to do a mt ... bsf 1 to back up to the file i wanted.
HOWEVER -- in your case, you probably had one tar file on the tape, but your tape now looks like one empty file immediately followed by "eom". In this case, do the "mt ... eom", do the writing trick in 2) above... rewind the tape, do a "mt ... fsf 1", and now the next file on the tape will be the junk file spliced together with your original tar file, hmmmm, the block size will be messed up, so you might need to experiment with dd a bit to andle it -- maybe, to probe the boundry where the splice happens, skip, conv=noerror, and a large input block size might be helpful...
i imagine other people might have experiences closer to your exact situation from which to offer advice... i would suggest waiting till you gather as much advice as possible before risking further havoc on your tape :-).
good luck, russell ruby russ@math.orst.edu
--- end of included message ---
------------------------------------------------------------ From: Postmaster <Piete.Brooks@cl.cam.ac.uk>
* I have heard, but never tried ....................... be ware ...............
* Go to the new EOM. Start writing. Remove power from the drive. * Now it is sitting after the EOM ...
* Power drive on again (& hope it doesn't rewind !) and read .....
------------------------------------------------------------ From: sbeard%london@gte.com (simon beard)
Gooday! the answer is yes; use mt.
ie: mt -f /dev/nrst0 fsf 1
the above command will skip over the first EOF on rst0 without rewinding.
You can then use restore ivf /dev/rst0 to go in and get what you want.
Hope this helps.
Simon.
------------------------------------------------------------ From: Perry_Hutchison.Portland@xerox.com
Depending on how the st driver handles the Exabyte tape, something like the following might do the job. I would suggest trying it with n set to each of 1, 2, and 3, ejecting and reinserting the tape between attempts in the hope of avoiding the problem of the driver "remembering" how many files are on the tape and blocking the attempt to space past what it thinks is the last one.
% mt -f /dev/rst8 rewind % mt -f /dev/nrst8 fsf $n % dd if=/dev/nrst8 bs=126b of={whatever} conv=noerror
The plan is to skip past n filemarks, then try to read. There should be either one or two filemarks following the new file at the beginning of the tape, and the first record following it/them will almost certainly be bad.
The goal with n=1 is to read whatever immediately follows the first or only filemark following the new file. If this sees an empty file with no errors, it probably means that there are two filemarks; if there is only one the first block will be bad but the remainder may be readable.
The goal with n=2 is to read the partial file in the two-filemark case, or to skip the partial file and try the next original file if there is only one filemark following the new file.
The goal of the n=3 attempt is to handle the case where the new file is followed by two filemarks, and the bad block following the second filemark is sensed by the driver as EOM so that it refuses to attempt any further operations, by skipping the partial file. It is hoped in this instance that the bad block/EOM condition will not be noticed during a skip-to-filemark operation.
If none of this works, it may be time to contact a data-recovery company.
------------------------------------------------------------
-- Todd Pfaff \ Internet: todd@flex.eng.mcmaster.ca Dept. of Mechanical Engineering \ Voice: (416) 525-9140 x2902 McMaster University \ FAX: (416) 572-7944 1280 Main Street West \ Hamilton, Ontario, CANADA L8S 4L7 \
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:45 CDT