Exabyte Summary (was Re: Mystical Parameters...)

Eric W. Ziegast ziegast at eng.umd.edu
Wed Jan 16 14:13:34 AEST 1991


Mike Bell writes:
>Could anyone recommend the best parameters for using tar or dump with an
>Exabyte 8200 8mm tape drive? Also, should the tape drive be /dev/rst0 or
>/dev/rmt0?

/dev/nrst0 is a good device to try. (No-rewind) For some warped reason, I
use /dev/nrst8, but it doesn't matter.  As for tar, whatever defaults sun
uses for tar are fine.

	tar cvf /dev/nrst0 [files/directories]

As for (r)dump, read on...

> From: "Brian H. Powell" <brian at natinst.com>
> Subject: SUMMARY-8mm dump parms
> 
>      I've received about a dozen responses, and the general consensus seems to
> be that, since nobody (who responded) has filesystems as big as 2 Gigabytes,
> it doesn't matter what you use for the dump parameters, as long as they
> indicate the tape can hold at least 2.3G.
>      I got varying responses about the blocking factor (20, 56, 64, and 126).
> I heard (but have no evidence to support) that the blocking factor doesn't
> matter; that the exabyte always uses its own block size, and buffers data
> until it gets that much.  I also heard that people occasionally have problems
> using large block sizes over a network with rdump.
>      Some people (with whom I agree) insist that you need to lie to dump
> about the tape parameters.  My impression about why this is needed is that
> dump assumes that the tape density won't exceed (my guess) 64K.  So you either
> use a real big size parameter, or a combination of a large density and a
> large size parameter.
>      The responses are below.  Thanks to everyone.  Have fun.

[shortened for actual dump parameters]

> dump 0unsdbf 6000 54000 126 [file system/device]
> rdump 0usf 120000 tapemaster at marvin:/dev/nrmt0h /dev/roota
> rdump ${level}uncsdf 346 466033 /dev/nrst1 /dev/xd0a
> rdump u0bdsf 56 54000 6000 /dev/nrst0 /dev/rpart# >>&! /usr/adm/backup.log
> rdump 0ubsdf 20 6000 54000 /dev/rst1 [file system/device]
> rdump 0bdsfnu 126 54000 6000 hostname:/dev/nrst0 partition
> rdump 0ufs venus:/dev/nrst1 126000 /dev/rxy0a.
> dump 0ubsdf 56 5190 4100000 [file system/device]
> rdump 0ucbsf 126 160000 discovery:/dev/nrst1 /dev/rsd1g
> rdump 0ufbs sunrise:/dev/nrst1 64 125000 /
> rdump 0ufbsdc tapehost:/dev/nrst0 100 6000 54000 /dev/rsd0a

My notes:

- On all entries that use the "f" option, I've changed the command from
  dump to rdump.  Though dump and rdump are the same on Suns, you will
  notice that dump won't work on some other OS's like Ultrix using the "f"
  option.

- I also believe that some of the parameters (density and length) are
  ignored.  Blocking factor though may make a difference.  One person made
  an argument that 56 should be the max BF on the 8200 because of it's
  buffer size (???).

- Any command which causes the Exabyte to "fsf" or "asf" past the last
  filemark on a tape will cause the Exabyte to hang indefinately.  The
  command "mt eom" does the same (it shouldn't).  This is only my own
  observation.  I have to reboot the Sun on which it's attached to correct
  this.

- One must specify the "o" option and remove "b" in Ultrix.

- I have never seen an official posting or mailing anywhere regarding the
  Exabyte 8200 models from its makers.  Any info I have ever encountered
  has been by word of mouth.  This is not good.

Questions concerning 8mm dump parameters are common.  I will keep this
article to respond to potings in alt.sys.sun and comp.sys.sun in the
future.  If I'm wrong in any of the info above, please mail me.  Horror
stories and helpful hints are also welcome.

Eric W. Ziegast, University of Merryland, Engineering Computing Services
ziegast at eng.umd.edu - Eric@(301.405.3689)



More information about the Comp.sys.sun mailing list