rcodi@yabbie.rmit.oz (Ian Donaldson) (02/10/88)
Does anybody know whether there is a difference in the actual -data-
recorded on an Apollo RBAK format 1/4" Cartridge versus the same data
recorded on an Apollo RBAK format 9-track 1/2" magtape?
(yeh, I know the block sizes are fixed at 512 bytes on a cartridge)
Why do I ask this? Well, its a long story...
We received this Cartridge containing about 18Mb of data, but our
DN660 (running SR9.2.3) has only a 1/2" 1600-bpi magtape drive.
However, we have a Sun-3 with a cartridge drive, so I thought that I might
as well read the tape there, then sendfile it up to the Apollo.
(it was QIC-24 format as far as the Sun thought, and "cat -v" verified
that it was not total garbage).
Upon the data arriving on the Apollo (all 18Mb of it in 18 or so files, one
file for each logical file on the tape), I thought that I'd just use
RBAK to decode it. No go! RBAK won't read from -anything- other than
a -real- tape. RWMT (the Apollo ANSI tape reader/writer) won't either.
Hmm, I thought. Why not write the stuff back to a 1/2" tape now that
it is on a machine that has one, and then use RBAK or RWMT to read it
back and unpack it?
The only problem with doing something like this is that RBAK and RWMT
expect the block sizes on tape to be EXACTLY right or they just
pewk at the sight of it.
Not knowing what the block sizes should be, I grabbed another RBAK magtape off
the shelf and discovered (by reading it on a VAX with dd) that the block sizes
were 80 bytes for the HDR1 and EOF1 blocks, and 8192 for the data in
the middle. 3 physical tape files per logical file. HDR1, data, EOF1.
I managed to generate a perfect copy of this RBAK magtape on the DN660 without
using WBAK (I used dd with the above block sizes), and upon reading
it back, RBAK liked it too. Great!
However, upon doing the same thing with the data from the Cartridge tape
RBAK -still- pewks at it!
Looking at the first header block from the real RBAK tape I wrote and the
data from the cartridge, there is only one startling difference -- there
is a lot more junk after the header in the Cartrige version. Also, the
cartridge version's header file was 2560 bytes long, but the magtape one
was only 400 bytes.
Hmmm again. Maybe this is not RBAK format? Well, I put the original
Cartridge in another department's DN3000 (running SR9.5) and it
reads perfectly with both RBAK -and- RWMT!
I can't find any Apollo doco about RBAK format anywhere, but I'm told
it is close to ANSI compatable, except that the acl formats, special file
info, directory info etc are not. An ANSI reader would skip all this
stuff since it is just part of the file data.
(incidently, I have another ANSI reader (ansii) grabbed from the net some
time back, which also pewks at it)
Any clues on how to convert RBAK cartridge data to magtape?
... or to unpack RBAK cartridge data once it is -off- the cartridge?
... or is it a difference between SR9.2 and SR9.5?
(I have no idea which version of Aegis the tape was written under)
... short of the obvious:
- pay somebody some enormous sum that has both drives to do it
- use two machines networked together to do it
(can you run the Ring via telecom? :-) Just joking.
Since we are likely to do a lot of this sort of thing in the future,
we would prefer a better method.
Ian Drcodi@yabbie.rmit.oz (Ian Donaldson) (02/11/88)
In article <692@yabbie.rmit.oz>, I wrote: > Looking at the first header block from the real RBAK tape I wrote and the > data from the cartridge, there is only one startling difference -- there > is a lot more junk after the header in the Cartrige version. Also, the > cartridge version's header file was 2560 bytes long, but the magtape one > was only 400 bytes. Well, I discovered what this was due to. When WBAK writes to a cartridge, it writes the HDR and EOF physical files as 80-character blocks, but they get padded to 512 bytes by something (the controller probably; maybe WBAK) with garbage. A quick program can be used to strip this garbage out: (error processing omitted for clarity) "xdd.c": --------------- |main(argc, argv) |char *argv[]; |{ | char *buf; | register int cc, input, output, ibs, obs, r; | | input = open(argv[1], 0); | output = creat(argv[2], 0666); | ibs = atoi(argv[3]); | obs = atoi(argv[4]); | | buf = malloc(ibs); | r = 0; | while((cc = read(input, buf, ibs)) > 0) { | if(cc > obs) | cc = obs; | if(write(output, buf, cc) != cc) | perror("write"); | r++; | } | | printf("%d blocks\n", r); | (void) close(output); |} --------------- Well, using this program on the cartridge data makes it ANSI compatable, (ie: RWMT likes it) but RBAK still chokes on the data blocks. I suspect this is because RBAK "knows" its is reading from a magtape and expects the data blocks to be 8192 bytes long (c.f. 512 for a cartridge). The following script output demonstrates: (f1 is a HDR file, f2 is a data file and f3 is a EOF file) --------------- |Script started on Thu Feb 11 12:26:36 1988 |% xdd f1 /dev/rmt12 512 80 |5 blocks |% xdd f2 /dev/rmt12 512 512 |19 blocks |% xdd f3 /dev/rmt12 512 80 |2 blocks |% rwmt -dev mt -index | |Volume label: | Volume ID: " " Owner ID: " " Access: " " | |File/Section File ID Cr Date Acc RF RL BL | 1 1 87/11/17 F 512 512 | |End of file set. |% rbak -dev mt -index -all -f 1 | |Label: | Volume ID: | Owner ID: (no owner specified) | File number: 1 | File section: 1 | File ID: (no id specified) | File written: 1987/11/17 11:19:53 ASET | |Starting index: | | |** Block length incorrect on data block 256 | Should be 536870916; is 512. Skipping this block. | |** Block length incorrect on data block 512 | Should be 536870916; is 512. Skipping this block. | -------- ...blah blah blah for a while -------- | |** Block length incorrect on data block 4864 | Should be 536870916; is 512. Skipping this block. | |Index complete. |% ^D |script done on Thu Feb 11 12:29:50 1988 --------------- What the 536870916 means I don't know. I suspect it is a bug. On observing the data file format using od, it appears that there are headers on every block. Since it came from a cartridge, this means every 512 byte block contains a header which has the pathname in it along with other binary stuff. If it came from a WBAK'd magtape, this header is only every 8192 bytes. [One wonders how efficient the cartridge is storing user data when the header is in -every- block! if the pathnames reach 100 chars long, then only 400 odd bytes per block are for user data it would seem! Obviously the headers are replicated to help ease read-error recovery.] Now, If I knew what the data part of RBAK format was, I could (reluctantly) write a converter to shift the headers, or just plain unpack the data! Another question: why is it not possible to do this: dd <file >/dev/rmt12 but this -is- possible: dd if=file of=/dev/rmt12 under bsd4.2? The former writes zero-length blocks onto the tape (ie: no data, just EOF marks). If it was reading from tape then it reads no data. "dd" is not broken, since it does the same with any other program (eg: my xdd above, until I rewrote it to open/creat instead of using fd 0/1) Ian D
Jinfu@cup.portal.com (02/17/88)
This not an answer to your question, rather I have more quesitons about r/wbak too. Does anyone know about the difference about the UN*X tar format and the ANSI format (all the levels)? Is there anyway to create a tar file without using UN*X? Jinfu Chen Motorola Inc., Arpa: Jinfu@cup.portal.com <-- has nothing to do with Motorola
krowitz@mit-richter.UUCP (David Krowitz) (02/18/88)
The UNIX tar tape is a completely different format than the ANSI tape format. Each file on an ANSI tape comprises three physical files -- a short ascii header which contains the name of the file, the record and block sizes, etc; the actual data of the file written with the record and block sizes specified in the header; and a short ascii trailer which contains some of the info from the header and also notes whether the file is complete or whether it continues onto a second tape. The actual data in an ANSI tape file can be almost anything. You can write one disk file to each ANSI tape file and give the tape file the same name as the disk file. The VAX/VMS command 'copy dsk:*.ftn mta0:' will copy all of the fortran files from the current directory to the tape - one file per ANSI tape file, with the file name in the header the same as the file name on the disk. You can then use RWMT -I to index the tape, see all of the file names and the block and record sizes, etc. RWMT -R -ANSI will read such a tape just fine. On the other hand, what WBAK/RBAK does is to take all of the disk files that were specified and pack them up into a single ANSI tape file which includes their ACL's, time/date of creation, etc. The ANSI file header contains the name of the backup set as the name of the tape file. The trailer notes whether the backup set fit onto a single tape or continued onto a second tape. Since each ANSI tape file is an entire backup session, it's easy to put another backup set into the second (or third, forth ...) ANSI file on the tape. If you use RWMT -I on a tape created by WBAK, the files you'll see are the complete backup sets on the tape (ie. the first tape file is WBAK -F 1, the second is WBAK -F 2, etc.) and the file names shown are the names of the backup sets as specified with the WBAK -FID switch, not the names of the files that were backed up (which are embedded in the data of the ANSI tape file). The tar format is a completely different format. It is not ANSI compatible. It can not span more than a single tape. There are no header and trailer files which can be used to name the backup set. The ANSI tape format is operating system independent. The tar format is used only by Unix systems. For system backups, most Unix systems use the dump/restore programs, since these can handle multi-tape backups. Unfortunately, dump backs up an entire disk partition, not just the files and directories you specify. Tar on the other hand will back up only those files you want backed up, but since it can't handle multi-tape backups it's pretty unless for system backups. WBAK/RBAK gives you the flexibility to do both, but you can't talk to a Unix system. It's kind of frustrating. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu mit-erl!mit-richter!krowitz@eddie.mit.edu mit-erl!mit-richter!krowitz@mit-eddie.arpa krowitz@mit-mc.arpa (in order of decreasing preference)