Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!sgi!shinobu!odin!anchor!olson
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: Exabyte on Personal Iris
Keywords: exabyte, PI
Message-ID: <9875@odin.corp.sgi.com>
Date: 2 Jul 90 19:54:48 GMT
References: <3306@usceast.UUCP> <9815@odin.corp.sgi.com> <2666@dftsrv.gsfc.nasa.gov>
Sender: news@odin.corp.sgi.com
Organization: Silicon Graphics, Inc.  Mountain View, CA
Lines: 37

merritt@iris613.gsfc.nasa.gov (John H Merritt) writes:

| In article <9815@odin.corp.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:
| 
| [Discussion of 8mm on PI]
| 
| >
| >If you have 3.2, there may be problems putting multiple archives on the
| >same tape if you use bru or tar (it will sometimes rewind when it
| >shouldn't, overwriting your earlier archives).  This problem is fixed
| >in 3.3
| I'm running 3.2 and my solution is:
| 
|    tar cBf - file | dd of=/dev/nr8mm bs=10240
| 
| I let dd handle writing and reading of the device and I position with
| 'mt' commands.


Yes, this will work around the problem, as the problem occurs in an ioctl
that tar uses, and it can't use it if it's output isn't a tape.

I would recommend for performance reasons using bs=128k, instead of 10k.
This GENERALLY reduces the amount of repositioning required on the
Exabyte, and therefore improves throughput.  Your system, may of course do
better with other values...  You may also want to consider using a larger
block size than the default (10k) with tar, for the same reason.

I am a bit hazy on the fix to the problem, but I seem to recall that if
you just specify a block size to tar, that the multiple archives per tape
problem will not be seen (i.e., the problem occurred when trying to
determine the blocksize to use).
--

	Dave Olson

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