taylor@limbo.Intuitive.Com (Dave Taylor) (03/01/90)
I have a 7912 disk image backup on a cartridge tape that I'd like
to be able to put into my 9144 tape drive and copy, byte-for-byte,
onto my HP-UX disk, then munge about in. The disk image is in no
known format (it's a long story) so I figured that I could use the
handy "tcio" command to suck in the entire tape worth of data, and
then write my own utilties to go further.
Problem is, "tcio" refuses to read past the first end-of-tape mark,
which occurs 96 1024byte blocks into the tape. I *know* that the
tape has at least 25000 valid 1K records on it, but I just can't
figure out how to get tcio to move past the end-of-tape mark (or
to write my own program to do the copy, which is a perfectly
fine alternative).
What I'm seeing is:
% tcio -ivZ /dev/rct
tape size: 65408 blocks
tcio(1009): 1024 byte blocks read: 96
What's wrong? What do I need to do to get past this point on the
tape? Alternatively, what fcntl() calls must I make once a program
I might write were to stop at this point?
Thanks greatly for any assistance you can offer.
-- Dave Taylor
Intuitive Systems
Mountain View, California
taylor@limbo.intuitive.com or {uunet!}{decwrl,apple}!limbo!taylorkinsell@hpfcdj.HP.COM (Dave Kinsell) (03/02/90)
> . . . but I just can't >figure out how to get tcio to move past the end-of-tape mark (or >to write my own program to do the copy, which is a perfectly >fine alternative). The tape is randomly accessable, with a 1K logical block size. I don't know why you couldn't just start doing reads from a C program at the block following the eot mark. Dave Kinsell
paulp@hpfcdc.HP.COM (Paul Perlmutter) (03/02/90)
I have a couple of questions:
- What does the kernel message buffer indicate. If it
is reading and EOF, then the driver will log this
in the buffer.
- If it is an EOF mark, what is it doing there, and
how do want to copy it? (e.g. skip it, or reproduce
it on the disk as a block of all 0's?)
Two options in any case are available, each with tradeoffs:
(assuming it is a tape mark)
(1) use 'tcio' - this can be achieved with an option:
-f n
where n indicates number of tape marks to skip.
Thus, by clever repeated use of 'tcio', you
can read the entire tape.
(2) write your own program: this is perhaps the more
time consuming, but at least you'll have control
of what's going on. Essentially, you will copy
the tape - even on error, copying a block of zeroes
when an error or tape mark is encountered. Here is
the critical loop:
char zerobuf[1K];
main()
{
char *ptr, buf[1K];
for (i=0; i<tape_size_in_blks; i++) {
ptr = zerobuf; /* Null buffer */
if ((ret = read(fd9144, buf, 1K)) == 1K)
ptr = buf;
if ((ret = write(fd_disk, ptr, 1k)) != 1K)
perror("error in write"), exit(1);
}
}
Use diskinfo -b to determine tape size in blocks.
> % tcio -ivZ /dev/rct
> tape size: 65408 blocks
> tcio(1009): 1024 byte blocks read: 96
A tape (hard) error may be causing the tape to bomb out too!
Cheers,
Paul Perlmutterpaul@hpldola.HP.COM (Paul Bame) (03/02/90)
Hi Dave! There are two questions here: 1) What does the image tape contain (HP-UX filesystem?) 2) How was the tape written (stated as unknown) I'll assume image was probably made with either the built-in "switch backup" or using dd(1) or an equivalent program maybe on Pascal Workstation. To find out what the image tape contains, remember that most HP stuff produces LIF volumes - even HPUX looks like a LIF volume. Here's what I find out by using 'lifls' on my 7.0 root disc: # lifls -l /dev/root volume BOOT data size 20 directory size 1 filename type start size implement created =============================================================== SYSHPUX -5822 3 20 ffff0800 00/00/00 00:00:00 SYSDEBUG -5822 3 20 ffff0800 00/00/00 00:00:00 SYSBCKUP -5822 3 20 ffff0800 00/00/00 00:00:00 You can try this on your tape. If it resembles this you have an HP-UX image of some vintage. If 'lifls' finds nothing, you've probably got a tape written with some other method like tcio and you can disregard the rest of this. If it contains a relatively recent (HFS) HP-UX file system image, you can probably mount(1M) the tape as a disc. This is slow and tortures your tape drive - you'll need a *block* CS80 device for the tape drive in order to mount it. To remove all the oxide on the tape and ruin your tape drive, run 'fsck /dev/rct'. To save this wear and tear you can copy to a disc. It has to be a *SPARE* disc at least as big as a 7912 - this'll obliterate it! $ dd bs=something-big if=/dev/rct of=/dev/sparedisc This'll take a while but is dumber than tcio and does the right thing with true image backups (not made with tcio). Then you can 'lifls' the disc just as you did the tape and/or mount the disc (you might want to try fsck(1M) first however). If it is an older BFS-format file system you'll get to explore the bfs*(1) utilities - but the 'dd' is still what you want. If it's a LIF disc from a BASIC or PASCAL workstation, the lif*(1) utilities are all you need - and may even be tolerably fast just on the tape without restoring it to disc. If you haven't got a disc you can completely obliterate, cry out and I'll suggest some other ideas - this is getting long. -Paul Bame #define DISCLAIMER These do not represent the official opinions, policies, \ or suggestions of Hewlett-Packard. Use at your own risk. P.S. Back up everything - just in case. P.P.S. I skipped lots of things I just *assume* Dave knows - don't try this at home!
djw@hpldsla.HP.COM (03/03/90)
> Problem is, "tcio" refuses to read past the first end-of-tape mark, > which occurs 96 1024byte blocks into the tape..... If it just a one time, can't you read the whole tape image with dd(1)? Something like: dd if=/dev/rct of=image bs=8196 I'm not sure on the block size, but I think as long as it is a 1k multiple it should work ok. I don't know if there is some stuff on the front of the image backup - I don't think so - I think it is just the disk image - anyone else? djw@hpldsla.hp.com