appending to tape archives
Dave Olson
olson at anchor.sgi.com
Wed Apr 11 06:13:36 AEST 1990
In article <127 at cutmcvax.OZ> architec at 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.
More information about the Comp.sys.sgi
mailing list