Many thanks to the many helpful answers to this question. Turns out RTFM was a
good reply--provided one has the 4.1.1 man page for dump!
For those without, the default density for 8mm tape is 54000 bpi and default
length is 6000 ft. The default track number is not listed. (I don't
understand the 6000 ft default either.)
Things are not that simple. Apparently, there are all manner of dump setups
that actually work. Here are a handful of those suggested:
----------
We use
dump 0fubsd /dev/nrst0 $blocksize 5190 4100000 filesystem
Where blocksize is 56 on our suns and 28 on our sequent. This
anamoly is because the suns treat blocksize as "n" 512 byte blocks
but the sequent dump treats it as "n" 1024 byte blocks.
---------
We have been using:
/etc/dump 0udbsf 54000 126 6000 /dev/nrst1 /dev/sd0a
The blocking factor (126) seems to be appropriate from a few non-structured
tests about two years ago. You might wish to listen for other comments
or experiment some yourself. I have often seen a blocksize of 100 used.
---------
We use these parameters with much success
0uncsdf 346 466033
---------
We use:
/usr/etc/dump 0ubsf 126 165000 /dev/nrsmt0 /dev/xy0a
---------
/usr/etc/rdump 4ubdsf 80 54000 160000 jekyll:/dev/nrst1 /dev/xy0e # /home
---------
We use the following for our 8mm drive
/etc/rdump 0cbsuf 400 20000 $dump_host:$dump_tape
---------
... and so forth. You get the point: dumping onto 8mm tape seems to be more
art than science. Many thanks to those who replied:
"Ric Anderson" <ric@cs.arizona.edu>
Tom Conroy <trc@NSD.3Com.COM>
hall@bond.crim.ca (Ron Hall)
"Matt Crawford" <matt@oddjob.uchicago.edu>
don@doug.med.utah.edu (Don Baune 581-6088 MIRL)
George A. Planansky <gplan@aer.com>
brianc@jekyll.ucsf.EDU
morrow@cns.ucalgary.ca (Bill Morrow)
rwolf@dretor.dciem.dnd.ca (Robert J Wolf)
bchivers@smiley.mitre.org (Brent Chivers)
Howie Kaye <howie@ivory.cc.columbia.edu>
erueg@cfgauss.uni-math.gwdg.de (Eckhard Rueggeberg)
pilotti@Proto.SAIC.Com
david@msri.org (David Mostardi)
rr6204 <@ada3.ca.boeing.com:rr6204@moses.boeing.com>
keves@meaddata.com (Brian Keves - Consultant)
era@niwot.scd.ucar.EDU (Ed Arnold)
Ken Nawyn <ken@nynexst.com>
sjh@helicon.math.purdue.edu
antonis@intracom.gr (Antonis Kyriazis)
keith@odi.com
Tad Guy <tadguy@ab00.larc.nasa.gov>
greg@glory.edm.so.apl.cul.ca
beauchem@DMI.USherb.CA (Denis Beauchemin)
d1!rkh@att.att.com
"John R Ruckstuhl Jr" <ruck@alpha.ee.ufl.edu>
daniel@canr.hydro.qc.ca (Daniel Hurtubise)
"Bill Gray" <bill@utkux1.utk.edu>
debra@fennel.acc.com (Debra Tivetsky)
marquard@astrosun.TN.CORNELL.EDU (J. Marquardt Sys Admin)
brewer@bilbo.memst.edu
ept@eptsun1.ctd.ornl.gov (E P Tinnel)
Gary Barber <gary@seismo.gps.caltech.edu>
Leon M. Clancy <lmclan@icase.edu>
Calum Mackay <calum.mackay@mrc-applied-psychology.cambridge.ac.uk>
Pravir K Chawdhry (EDC Data Exch) <P.K.Chawdhry@newcastle.ac.uk>
Vincent Ackermann <vinack@tech.ascom.CH>
heiser@sud509.ed.ray.com (Bill Heiser - Unix Systems Admin)
ks@ee.ecn.purdue.edu (Kirk Smith)
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:18 CDT