>>> I also find it annoying that I can't (easily) dump more than one file
>>> system on a tape.  Do I really need a separate tape for my 16 meg root
>>> partition?
>> 
>> Doesn't the non-rewinding tape device work?  I put 5-6 dumps on one tape,
>> without any problems.
>
> I suppose I could do that, but I'm a bit nervous, since the multi-file
> handling on tapes doesn't seem particularly robust to me.
>
> In particular:
>  1. After reading one file, it takes more than one attempt to read the
>     following file.
>  2. It seems that it is possible to read past the EOF and keep going to
>     the next file without closing/reopening the driver.  (This is just a
>     guess though)

As I show below, while the behaviour you're seeing is "correct", multiple
files are working correctly.  NetBSD dump/rdump don't rewind the tape
on device close unless you specify the rewind device, so putting multiple
dumps on a tape is dead easy (and it's been reliable for me).


> This doesn't inspire confidence, although I admit I've seen the same
> thing on SunOS.  Could someone briefly explain the semantics of
> multiple files on a tape device?

Let's see...  Your writing phase:

	> mhw ~/tst % mt rewind

	Tape is at BOM.

	> mhw ~/tst % tar c a

	Tar writes an archive and closes the device, which writes an EOF marker
	to the tape.

	> mhw ~/tst % tar c b
	> mhw ~/tst % tar c c

	And again, and again...

And now your reading phase:

	> mhw ~/tst % mt rewind
	> mhw ~/tst % tar t
	> a

	Tape is at the end of the tar archive, _on_ (or just before) the
	EOF marker.

	> mhw ~/tst % tar t

	Tar reads the EOF marker and gets a null archive.  The tape is now
	at the start of the next archive.

	> mhw ~/tst % tar t
	> b

	Tar reads the next archive, leaving the tape on the next EOF.

	> mhw ~/tst % tar t
	> mhw ~/tst % tar t
	> c

	etc...

You should find the following behaviour:

	% mt rewind
	% mt fsf
	% tar t
	b
	%

	"mt fsf" leaves the tape immediately after the EOF, at the start
	of the following file.
	Unfortunately, the behaviour of "mt bsf" is not so easy to predict
	across variations of OS and tape drive, and my experience leads me
	to classify it as "undefined".

And for your next phase:

	> mhw ~/tst % mt rewind
	> mhw ~/tst % tar ti
	> a
	> a
	> b
	> b
	> c
	> c
	> c
	> c
	> c
	> c
	> c
	> c
	> ^C

	What do you expect when you tell gnu-tar to ignores nulls and EOFs?
	Why did you add the 'i' option?  Surely this is only for last-ditch
	recovery of data from stuffed tapes?

I hope this explanation helps.

- David Burren
  davidb@werj.com.au
  davidb@melb.cpr.itg.telecom.com.au

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