[comp.sys.sgi] appending to tape archives

architec@cutmcvax.OZ (Phil Dench ) (04/10/90)

All this talk about mag tapes has reminded me to post the following.

Does anyone know how to append to existing data on a 1/4" streamer
cartridge mag tape?

I used to be able to do this under 3.1 (but always suspected it was a
bug not a feature) ...

    fd = check_open( "/dev/tape", O_WRONLY | O_APPEND);

... and any subsequent writes would happily append.

Now under 3.2 this just overwrites the first file on the tape.
Anything else I try does the same sort of thing. I cant even do a fsf
then a write because of (from mtio(1)) ...

    A tape is normally open for reading and/or writing, but a tape
    cannot be read and written simultaneously.  After a rewind, an
    unload, or an MTAFILE ioctl, writes may follow reads and
    vice-versa ...

A rewind is no good to me. MTAFILE doesn't work on a 1/4".  And am I
correct in assuming the unload is just an 'mt offline'?

It would be real useful if I could append.  Cartridge tapes cost $60
Australian here.  I don't want to use one for each little project that
I'm archiving.  And I dont really want to restore all the old ones on a
tape just to write them all back with a new one on the end.

    Phil Dench

--------------------------------------------+----------------------------------
                                            | School of Computer Science,
ACSNet: architec@cutmcvax.oz                | Curtin University of Technology,
UUCP:   ...!uunet!munnari!cutmcvax!architec | Kent Street,
ARPA:   architec%cutmcvax.oz@uunet.UU.NET   | Bentley
                                            | Western Australia, 6102
--------------------------------------------+----------------------------------

olson@anchor.sgi.com (Dave Olson) (04/11/90)

In article <127@cutmcvax.OZ> architec@cutmcvax.OZ (Phil Dench ) writes:

| All this talk about mag tapes has reminded me to post the following.

| Does anyone know how to append to existing data on a 1/4" streamer
| cartridge mag tape?

| I used to be able to do this under 3.1 (but always suspected it was a
| bug not a feature) ...

|     fd = check_open( "/dev/tape", O_WRONLY | O_APPEND);
| ... and any subsequent writes would happily append.

Are you SURE of this?  To my knowledge none of the tape drivers for the
4D series have ever paid any attention to O_APPEND, so it would have been
treated the same as O_WRONLY and started writing at BOT, or EOD, depending
on your current tape position.

| Now under 3.2 this just overwrites the first file on the tape.
| Anything else I try does the same sort of thing. I cant even do a fsf
| then a write because of (from mtio(1)) ...
|     A tape is normally open for reading and/or writing, but a tape
|     cannot be read and written simultaneously.  After a rewind, an
|     unload, or an MTAFILE ioctl, writes may follow reads and
|     vice-versa ...
| A rewind is no good to me. MTAFILE doesn't work on a 1/4".  And am I
| correct in assuming the unload is just an 'mt offline'?

unload is almost the same as offline for most drives.  The difference
is that unload will actually eject the tape for drives that support it.
You can do an 'mt feom' to position the tape at endofdata (EOD), and then
append new data, but you can't do an append in the 9track sense, where
there is no FM between the old and new data (and in the case of tar, the
block of 0's at the end is also backspaced over).  The QIC standard does
not allow for this, and none of our supported QIC drives allow it either.

| It would be real useful if I could append.  Cartridge tapes cost $60
| Australian here.  I don't want to use one for each little project that
| I'm archiving.  And I dont really want to restore all the old ones on a
| tape just to write them all back with a new one on the end.

If you can accept multiple archives on the tape, then this sequence will
work.  If you keep track of the archive number, you can use mt fsf # to
space to the one you want to list or extract from.
Unfortunately, there is a bug in the 3.2 tape driver that causes this
sequence to not work reliably for all drives; when it doesn't work, the
first archive can be overwritten.  So if the 'mt status' doesn't show
EOD, then don't do the tar cv!

first archive: tar cv ....
2nd thru N:	mt feom; mt status; tar cv ...

listing, you can do:
tar vtf /dev/nrtape; tar vtf /dev/nrtape; tar vtf /dev/nrtape; ...
or
mt fsf N; tar vt

If you don't specify the nrtape device, it will rewind at the end, but it
will NOT rewind or reposition before writing if you are at BOT, FM, or EOD.

Hope this helps.

	Dave Olson

Life would be so much easier if we could just look at the source code.

tarnoff@cme.nist.gov (Nicholas Tarnoff) (04/11/90)

I tried to email this message but it bounced.
   ----- Transcript of session follows -----
421 Host cutmcvax.oz not found for mailer ether.
550 <architec@cutmcvax.oz>... Host unknown


I do incremental backups automatically from cron.
You should:

mt rewind
mt feom     #Forward space to end of recorded data.
            #This allows adding new partitions to
            #already partially written tape.

bru -c -vf /dev/nrtape -s <###M such as 150M>

I also use  -BR and -n options. See the man page for bru.

Good luck.
-Nicholas
--------------------------------------------------------------------
NAME:  Nicholas Tarnoff (Robot Systems Division)
USMAIL:National Institute of Standards and Technology (formerly NBS)
       Bldg. 220 / Rm B127     Gaithersburg, MD 20899
TELE:   (301) 975-3464          ARPA:   tarnoff@cme.nist.gov
FAX:    (301) 990-9688          UUCP:   uunet!cme-durer!tarnoff
--------------------------------------------------------------------