Here's an old call to ufsdump. Which numbers, etc for gtar to tape?

Here's a ufsdump I used when I had ufs, not zfs:


/usr/sbin/ufsdump 0ucnbdsf 126 54000 13000 /dev/rmt/0cn /dev/rdsk/''$slice


Suppose I now want to gtar a big file foo.tar onto an empty tape;
what gtar command would I give, ie where if anywhere do those
numbers fit in?

I especially need to know what I use for the tape drive name.

(By the way, I currently have a VXA-2)

And, do I use a "c", as in cvf?

And that f there: that's the name of the file I'd
be *creating*, if I used "c".

But I'm not creating a file; I'm writing (appending)
to a tape.

Would I give a command like this?:

gtar [???]vf <name of tape drive, no rewind> <name of file to
be written/appended to the tape> > tarjob1.log


-------------------


Now, suppose I have three (.tar) files, and I'd like to put
all three onto the mag-tape.

So, after the first one, I sure want NO rewind to happen.

Ditto for after the second one.

So, it will be three gtar commands, one after the other:

gtar cvf -- no, that's not correct, I'm not creating
a new mag tape?

Anyway, in whatever command to write to the tape, what's that
"f" going to be?

And I suppose the final arg will be the name of the .tar-file
I want to write onto the tape.


QUESTION: is there any different result (on the tape) between
gtar .... file1.tar file2.tar file3.tar

and three separate commands?:

gtar ... file1.tar
gtar ... file2.tar
gtar ... file3.tar



-------------------------------------------- READING THE TAPE:


I suppose each of those on-tape files is called, in the mt doc,
a "record". A "file"? or what?

Hmmm. I just looked -- some commands use "file", others
use "record". Please, what's the difference?




Now, suppose I mount the tape I want to read, and I want to
read the THIRD of those .tar-files.

I do this, correct?: mt fsf 2 ...

or is it: mt fsr 2 ...

(What diff between the two?)

Here's my own (old) notes on mt:


erase <<===== BWR!!! ERASES **ENTIRE TAPE** <<===

BWR: eof, weof: BWR: these cmds WRITE <count> EOF-marks "RIGHT HERE".
fsf <count>: Forward Space over count "FILES" (actually, over EOF-MARKS), to
be positioned READY TO READ the count+1th "file".
(It will then be positioned on the first block of the "file").
fsr: Forward space <n> RECORDS.
bsf <count>: BACKSPACE over <n> EOF marks, readyToRead that EOF'ed file.
(bsf: NOTE the "note" below)
(NOTE: if status SAYS you're at file 17, but you WANT number 15,
then do "bsf 3", ie "diff+1"!!! (amAt - Want + 1) (PLUS ONE!!)




Thanks much for for the answers to these vary basic questions.

(I ask you guys because I *really* can't afford to screw up!)

David



.

Relevant Pages

  • gtar failing, please help!
    ... I have some backup scripts that manipulate a tape library and tape ... gtar to bsdtar in the base system, gtar fails to write any data ... I can't use dump or bsdtar because my data spans ...
    (freebsd-questions)
  • Re: Heres an old call to ufsdump. Which numbers, etc for gtar to tape?
    ... Suppose I now want to gtar a big file foo.tar onto an empty tape; ... what gtar command would I give, ie where if anywhere do those ... But if you have a tape that is faster then the disks, then it could be better to first create the foo.tar then write the file since then ... fsr: Forward spaceRECORDS. ...
    (comp.unix.solaris)
  • Re: gtar restore produces strange directories
    ... So the weird directory names seem to be a gtar ... if I use dd and create a tar file using dd ... past the same place on the tape. ... > see if I can restore the tapes created on the IBM on a Solaris system. ...
    (comp.unix.admin)
  • Re: gtar restore produces strange directories
    ... > Assuming that it was variable, is there any way to set up gtar or the ... > tape device settings to read the tape properly without using dd to ... I suspect that most tapes written on AIX are read again on AIX, ...
    (comp.unix.admin)
  • Re: gtar restore produces strange directories
    ... generated by the AIX system via the Solaris one. ... with the tape or with gtar. ... tar is able to extract it ok on the SUN box, but gtar dies on IO ...
    (comp.unix.admin)