Dumping to an exabyte tape drive

George Goble ghg at ecn.purdue.edu
Thu Sep 6 00:26:23 AEST 1990


>And in article <FPB.90Aug31172357 at schlitz.ittc.wec.com> fpb at schlitz.ittc.wec.com (Frank P. Bresz) writes:
>
>)
>)dump 0ufsd /dev/nrst2 6000 54000 /dev/id000a
>)
>
>These figures seem quite inconsisten. Which is correct?
>Would someone at SUN care to comment, ideally the person who wrote
>their drivers?
>
>A Standard Tape has a density of  6250 bpi and a length of  2300 feet
>
>Jim Tibbs specifies a density of 43000 bpi and a length of 12000 feet
>
>Derick Linegar specifies       4100000 bpi and a length of  5190 feet
>
>Frank Bresz specifies density of 54000 bpi and a length of  6000 feet
>
I can probably take the blame for "6000 54000".  We did lots of the
early Exabyte work on Suns (and turned our drivers over to Sun back in
the 3.4/3.5 days).  For both Gould's and Suns the older dump/restore
used "b 1" to mean 1024 bytes, not 512 as it does today.

Back then, we used "dump 0fbsd /dev/nrst0 50 54000 6000 /filesys"
and if filesys was 220 MB, it would give an estimate of "0.1 tapes".
Now we changed the 50 to 100 on the suns but have not checked
the accuracy for awhile.. this was 2-3 years ago.

In reality, the Exabyte (8200) is 550000 BPI and 347 feet long, but
those numbers cause overflow in dump.  The EXB-8500 is 2X the
"density" of the 8200 and will make these problems more severe.
Jim Kahn is the person who works on the "st" driver for non Sparc
Suns at Sun.

--ghg



More information about the Comp.unix.admin mailing list