GKN%OAK.SAINET.MFENET@LLL-MFE.ARPA (11/19/85)
Date: Tue, 19-NOV-1985 11:00 EST
To: Info-VAX@SRI-KL.Arpa
Message-ID: <[OAK.SAINET.MFENET].993450A0.008E6435.GKN>
Organization: Science Applications, Oak Ridge, TN 37830
Geographic: 36 01' 42" N, 84 14' 14" W
Telephone: (615) 482-9031
X-VMS-Mail-To: ARPA%"Info-VAX@SRI-KL.Arpa"
I am either going crazy, am hopelessly brain-damaged, am trying to do
something which I am not supposed to be able to do, or have my hands on
a real-live bug. Please help me decide; I can't stand not knowing :-).
I have this multi-volume VMS Backup save set which was created with the
following command:
$ Backup -
/Comment="Image backup of DRC0:"-
/Image-
/Log-
/Ignore=Interlock-
DRC0: MFA0:DRC0.BKP
From all external indications, this worked fine. Just dandy, in fact.
When someone went to restore a file from this volume set, they slapped
up the second tape in the set (the file in question was there, and there
was no point in searching a 3600' tape. The warning message you get when
you do this is harmless enough) and away it went. The file was restored
OK.
The command used was similar to:
$ Backup MFA0:DRC0.BKP/Select=([DIR]FILE.EXT;VER) DRC0:[DIR]/Owner=Parent
The problem comes when we want to restore a file which is on the first tape
in the volume set. Backup says "No" in various ways, mostly that it can't
find [000000]DRC0.BKP (and searches the entire tape ... ho hum), or
complains that it hits end-of-volume if the tape is positioned at BOT.
What's even worse it that I seem to be unable to get a listing of the save
set. Taking a look at the first few blocks on the tape with DUMP, we get the
following:
Dump of device MFA0: on 19-NOV-1985 10:52:06.84
Block number 1 (00000001), 80 (0050) bytes
20202020 20202020 20202020 20202020 20202020 20202045 47414D49 314C4F56 VOL1IMAGE 000000
20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 000020
33202020 20202020 20202020 20202020 3................ 000040
Block number 2 (00000002), 80 (0050) bytes
30313030 30204547 414D4920 20202020 20202020 20202020 20202020 31524448 HDR1 IMAGE 00010 000000
46434544 30303030 30302038 30333538 20383033 35382030 30313030 30303030 000000100 85308 85308 000000DECF 000020
20202020 20202020 20204131 31454C49 ILE11A ................ 000040
*** End of file ***
Block number 3 (00000003), 8192 (2000) bytes
00000000 00000000 00000000 00000000 00000000 00000001 00010001 04000100 ................................ 000000
00000000 00000050 4B422E30 43524408 00000000 00002000 6351BA71 00010101 ....q:Qc. .......DRC0.BKP....... 000020
00000000 00000001 19F30000 00000000 00000000 00000000 00000000 00000000 ......................s......... 000040
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000060
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000080
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0000A0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0000C0
8BCC0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ..............................L. 0000E0
0053504B 422E3043 52440001 00080101 00000000 00000000 00000000 00010100 ......................DRC0.BKPS. 000100
666F2070 756B6361 62206567 616D493D 544E454D 4D4F432F 50554B43 41420002 ..BACKUP/COMMENT=Image backup of 000120
434F4C52 45544E49 3D45524F 4E47492F 474F4C2F 4547414D 492F3A30 43524420 DRC0:/IMAGE/LOG/IGNORE=INTERLOC 000140
62206567 616D4900 03001550 4B422E30 4352443A 3041464D 203A3043 5244204B K DRC0: MFA0:DRC0.BKP....Image b 000160
00042020 20202020 4D455453 59530004 000C3A30 43524420 666F2070 756B6361 ackup of DRC0:....SYSTEM .. 000180
[there's more, but it's boring]
The first two blocks look like a normal tape label to me. The next block
looks for all the world like the start of a Backup save set, but apparently
Backup doesn't believe it. Am I supposed to be able to list the contents
of a save set made with the /IMAGE qualifier? The documentation doesn't
say that I can't (but it also doesn't say that I *can*).
Suggestions? Ideas? Flames?
Any help would be greatly appreciated...
gkn
-------------------------------------
Arpa: GKN%OAK.SAInet.MFEnet@LLL-MFE
USPS: Gerard K. Newman
Science Applications
P.O. Box 2501
Oak Ridge, TN 37831
AT&T: (615) 482-9031OC.GARLAND@CU20B.COLUMBIA.EDU (Richard Garland) (11/21/85)
It may be a problem in the label of the tape. Try 2 things: 1) BACK MFA0:/List ! or /Select etc. This will take the first file it finds, with what ever label. 2) Mount the tape with appropriate blocksize, and copy the save set. $ Mount MFA0:/Over=ID/Block=nnnnn $ Copy MFA0: Foo.Saveset Then do backup from disk, i.e. BACK Foo.Saveset/Save/List etc. Also just trying to Mount it (not foreign, but Filles-11) and doing a Directory may be reasuring and informative. Rg -------
goldstein@2124.DEC (Andy Goldstein) (11/22/85)
Sorry about this one, folks. We committed one of the classic no-no's
in tape handling: writing a label record after reading forwards. For
those of you not familiar with this bit of arcane magtape folklore,
the gory details follow:
A standard tape drive has separate read and write heads, with the
write head ahead of the read head, from the point of view of the tape
motion, so that the read head can read back and check what's just
been written. The two heads are separated by .15". This fact can get
you into trouble when you switch from reading to writing in the
middle of tape records. What happens to BACKUP is this:
You init a tape. This puts a VOL1 header label on the tape, followed
by header and trailer labels for an empty dummy file. The file is
recognizable as a dummy by the fact that it is given a zero sequence
number. Now you tell BACKUP to write a save set to the tape, using
the default tape handling, which is to append to the tape. BACKUP
recognizes the dummy file labels, rewinds the tape, and spaces over
the VOL1 label to write the real file labels for the save set.
At this point, things look like this:
*BOT* VOL1 HDR1 HDR2 *TM* .....
^^
||
|write head
read head
When you're dealing with GCR tape, the gap between the labels is only
.3", and the read head will have coasted a ways into the gap, meaning
that the write head is .15" further along. Now when you start writing,
the tape has to get up to speed before the write head turns on. By the time
this happens, HDR1 may have already gone by. (Remember that at 6250 BPI,
an 80 byte label record is microscopic.) The new HDR1 and HDR2 get laid
somehow on top of the old HDR2. The result is trash in the wake of
the old HDR1 that the tape drive can't make any sense of, so when
you try to read the tape back, all you see is the old HDR1; sanity
finally returns with the tape mark.
Anyway... BACKUP will get fixed in VMS V4.3, by rewriting VOL1 in this
circumstance. In the meantime, there's a workaround. The problem only
occurs when you write a save set to a newly inited tape using /NOREWIND
(the default). Therefore, if you're writing to a fresh tape, tell
BACKUP /REWIND, and you'll avoid the problem.