"Peter L. Peres" writes:
- Hi list, I posted this message a few days ago and there was no reaction. 
- My conclusion is that there may be potentially very bad problems with 
- tar used on st (scsi qic tape) devices. Is this a problem that was seen 
- by others, or am I the only one ? It seems to be related to the tar+st 
- combination since other programs (mt, dd) seem to operate correctly with 
- tar, and tar itself does not seem to have other problems. the net holds 
- some testimonies about problems with tapes under linux. Are they shared 
- by netbsd ?

	In my experience, magnetic tape support is quite good
under NetBSD..

	I've composed the rest of the reply intermingled with
the original posting below.

- ---------- Forwarded message ----------
- Date: Wed, 26 Jan 2005 00:16:18 +0200 (IST)
- 
- Hi, I have strange problems again:
- 
- st0 is a qic-150, it has file1 file2 file3 on it, in this order,
- put on by tar, on the same system. When I try to read any back,
- besides the first file, I get nothing from tar until the third
- (!!) try. See below:

	Did you put the three tarballs on the take using this
form:

	tar cf /dev/nrst0 <file list>;
	tar cf /dev/nrst0 <file list>;
	tar cf /dev/nrst0 <file list>;

- I issue commands like:
- 
- > export TAPE=/dev/nrst0
- > mt rewind
- > mt status
- SCSI tape drive, residual=0
- ds=3<Mounted>
- er=0
- blocksize: 512 (0, 0, 0, 0)
- density: 0 (0, 16, 15, 5)
- current file number: 0
- current block number: 0
- > tar tv 
- file1
- > mt fsf
- > tar tv <- nothing! $? is 0!
- > tar tv <- nothing! $? is 0!
- > tar tv <-this time it works ?!!
- file2
- 
- I tried this several times. What could cause this ? And why does
- tar not return an error code anyway ?! mt status after fsf shows
- file 1 block 0 (as it should). Is this a tar problem ? A mt
- problem ? A st problem ? A faulty drive or driver could not cause
- this (tar should notice a short archive and complain, no ?) so
- I think it's a tar problem.

	I think you're running into correct operation.

	Basically, the magnetic tape driver drops two filemarks
on device close to mark end of tape.  So, you've written a
tar archive to the tape device with tar, and it closed the device.
Two filemarks were written.

	Then you wrote another tar archive to the tape, with out
backing up over the second of the two file marks.  And again
with the third..

	So, your tape looks like this:

		tar archive
		file mark
		file mark
		tar archive
		file mark
		file mark
		tar archive
		file mark
		file mark

	When reading, tar just reads up to the "magic" EOF
marker that tar emits on writing. This doesn't correspond to the
EOF marker that is written by the tape device.  So, you get to
do ``mt fsf 1'' to get to the first file mark after the tar
archive.

	Your second read, tar reads EOF immediate, and exits
with success.

	I'm not sure why your third read isn't picking up the
next tar archive, but I'd guess it's because the tape hasn't
advanced past the filemark yet..

	You should be writing these tapes in the following
fashion:

		tar cf /dev/nrst0 <files>
		mt bsf 1
		tar cf /dev/nrst0 <files>
		mt bsf 1
		tar cf /dev/nrst0 <files>

	That way, the tape will look like:

		tar archive
		file mark
		tar archive
		file mark
		tar archive
		file mark
		file mark

	Which is what you want it to look like..

- Also, tar always leaves the tape at the current file, last block.
- Reading the tape with dd leaves the tape at the start of the next
- file, block 0.

	See the discussion above.  Tar(1) reads until it finds the
end of archive marker, and quits.  Since tar works on many
different media types (including regular files) it doesn't
really have much in the way of tape handling in it..

	dd(1) reads off the tape in the block size you
specify. It reads until it encounters an EOF marker (in this
case, a file mark.)

-               Additionally, if I use /dev/rst0 instead of
- /dev/nrst0 with tar, it rewinds and exits normally without
- extracting anything! This is dangerous!

	Depending on the tape position at the begining of the
command, ``tar xf /dev/rst0'' should read the current tar
archive, and then rewind the tape device upon close. (this is a
semantic of the rst0 device, rewind on last close.)

--
Eric Schnoebelen		eric@cirr.com		http://www.cirr.com
  "Linux in some ways is the Jerry Springer of operating systems, ..."
		 Bruce Becker in comp.sys.sun.wanted