mb@sparrms.ists.ca (Mike Bell) (01/11/91)
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? The documentation we received with the drive is remarkably terse, and designed for a different machine. Thanks.
kusumoto@chsun1.uchicago.edu (Bob Kusumoto) (01/15/91)
This is a repost from the article I sent to alt.sys.sun and
comp.periphs.scsi:
Well, after getting a few replies about doing 8mm dumps on a UNIX machine,
here are a summary of responses and at the bottom is my final situation.
X-From: chu@ims.alaska.edu (Chirk Chu)
We bought an Exabyte drive from Artecon and their manual suggested using
the tape length of 6000' and density of 54000. For example:
dump 0usdf 6000 54000 /dev/rst1 /home
would backup /home on st1 if you have your Exabyte drive configured as
st1.
X-From: danw@dragon.scs.com (Dragon Master)
After a _lot_ of experimentation over several weeks, we came up with the
following parameters:
dump 0ubdsf 126 6250 28633 /dev/rst0 /dev/rxy0h (or whatever filesystem)
This sets the block size to 126 - the density to 6250 (the max) - and the
tape length to 28633. We have found this will get the maximum amount of
info on a 8mm tape. We use this on seven systems to back up local and
remote file systems on >100 nodes.
X-From: trn@aplcen.apl.jhu.edu (Tony Nardo)
This is the command we use for our Exabyte backups, based on Exabyte's
recommendations:
/etc/dump 0fubsd /dev/rst2 100 6000 54000 /dev/sd0g # dumps usr partition
It does a moderately good job of estimating "time remaining" properly as
well as using the tape drive fairly efficiently -- backed up > 230 Mb onto
a tape in about 32 minutes *without* going to single-user mode on a trial
run.
X-From: jsalmi@solbourne.com (John Salmi)
I have conducted tests on 106m consumer 8mm videotapes. They work okay in
Exabyte drives, but you can only fit 1.075 gigabytes onto them. Two
gigabytes is the MAXIMUM tape size the drive will take, but 112 meters is
apparently not the largest size of tape available.
The parameters we use are
/etc/dump 0ubdsf 20 54000 6000 $tapehost:$tapedrive $fsname
The use of 20 rather than 50 as the block size reduces "broken pipe"
errors caused by large data blocks on the Ethernet (according to Sun).
Exabyte is a streaming drive and apparently always writes 126-block
records. The actual tape density is very high, too large a number for
'dump' to handle, so the 54000/6000 combination is used to fake the
desired tape length.
***
Well, I also was sent a script from the local sysadmin of the university's
computing organizations (UofChicago) that they use for doing backups, and
it had the following dump parameters that sounded good to me:
/usr/etc/dump udbsf0 6250 100 36000 /dev/nrrt0 $filesystem 2>&1 | tee -a $log
I guess the theory here is that you have to adjust the density and tape
size so that it tricks dump into using the tape to it's fullest. Blocking
factor of 100 is the one recommended by exabyte so I can live with this.
On a side note, I picked up a unattended backup demo called Budtool, and
on their 8mm tape backup system, they use a block size of 124 (but then
again, they also provide a program that monitors the quality of the tape
so that you can tell if the tape is awful or good after one backup. It's
also very good to check the quality of reused tapes so that you know when
to toss bad tapes. But the entire software system costs $4k so it's a bit
out of my reach). I believe they also use a denisty of 6250 and adjust
the tape size depending on how much tape has already been written to it to
figure out what parameter to give to the dump command.
I used the local dump parameters given to me and can say that we have
sucessfully backed up our system at a rate above 90MB/10 minutes (using
Wren VIIs, 17ms access time on 1GB drive, using format.dat parameters
different from one's provide by Sun in SunOS 4.1 because we didn't have
any at the time). It took around 40 minutes to back up roughly 375MB and
50 minutes to back up 475MB. Doing a full restore of the root and /usr
partitions took me roughly two hours (total size around 350MB). I also
was happy to report that I found a cheap source of the Sony 8mm tapes from
CCD in San Leandro, CA (phone # is (415) 352-3202) with costs under $5.50
when you order is sufficient quanity (we ordered 50 although I bet you can
probably get that kind of price if you order more that 25).
I certainly hope this helps everyone out there.
Bob Kusumoto | Find the electric messiah!
Internet: kusumoto@chsun1.uchicago.edu | The AC/DC God!
Bitnet: kusumoto@chsun1.uchicago.bitnet | - My Life with the Thrill Kill
UUCP: ...!{oddjob,gargoyle}!chsun1!kusumoto | Kult, "Kooler than Jesus"ziegast@eng.umd.edu (Eric W. Ziegast) (01/18/91)
In article writes: >This is a repost from the article I sent to alt.sys.sun and >comp.periphs.scsi: Dump parameters listed only. > dump 0usdf 6000 54000 /dev/rst1 /home > dump 0ubdsf 126 6250 28633 /dev/rst0 /dev/rxy0 > dump 0fubsd /dev/rst2 100 6000 54000 /dev/sd0g > dump 0ubdsf 20 54000 6000 $tapehost:$tapedrive $fsname > dump udbsf0 6250 100 36000 /dev/nrrt0 $filesystem After my last post to one of the newsgroups on this subject, I decided to call a company selling Exabyte drives (Perfect Byte) and asked what their opinions/recommendations are. They recommend like many others that you use 54000 density and a blocking factor of 126. The 6000 is only for the (Sun) dump program which only uses it for dump estimates. I learned some other things during my conversation about the Exabyte 8200. The drive itself gets its own information on tape length and other info about the tape *from the tape itself*. So it can tell whether you're using Sony 112M, TDK or whatever. So if you buy different tapes, the Exabyte will know how to handle each one. The "mt eom" command does not work under SunOS 4.*.*. The fault is on the part of the Sun st device driver. Perfect Byte has a device driver for SparcStations which is more "intelligent" for Exabytes (mt eom will work). There's a new model 8500 out there being tested. It takes a slightly larger than average tape, but it stores much more data per tape length than the 8200. Eric W. Ziegast, University of Merryland, Engineering Computing Services ziegast@eng.umd.edu - Eric@[301.405.3689]
zwicky@erg.sri.com (Elizabeth Zwicky) (01/19/91)
In article <1333@brchh104.bnr.ca> ziegast@eng.umd.edu (Eric W. Ziegast) writes: >The "mt eom" command does not work under SunOS 4.*.*. The fault is on the >part of the Sun st device driver. Either this is false, or I am subject to persistent hallucinations of the most peculiar sort; I've recently been doing data collection from our dump tapes with a program that starts by doing an "mt eom", and it's worked on at least two of our drives, and on over a dozen different tapes. Perhaps they mean not SunOS 4.*.* but SunOS 4.0.3, since we run 4.1, and we did have hangs on attempts to fsf past eom previously (using different drivers on different Suns on a different version of the OS, so I'm not willing to swear to the identity of the critical factor). The fault that I do know of in the Sun 4.1 st device driver is an irrational devotion to the concept of writing an eof mark when a device that has been opened for write is closed. This makes trying to write table of contents files at the beginning of a tape tricky at best; the old trick of moving the tape before the close no longer works, and you get erroneous eofs and a very unhappy tape. Elizabeth Zwicky (zwicky@erg.sri.com)