Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!noose.ecn.purdue.edu!en.ecn.purdue.edu!ghg From: ghg@ecn.purdue.edu (George Goble) Newsgroups: comp.unix.admin Subject: Re: Dumping to an exabyte tape drive Keywords: Exabyte dump args Message-ID: <1990Sep5.142623.25070@ecn.purdue.edu> Date: 5 Sep 90 14:26:23 GMT References: <1990Aug29.143657.20588@siesoft.co.uk> <1990Sep1.143812@suned1.nswses.navy.mil> <877@iiasa.UUCP> Organization: Purdue University Engineering Computer Network Lines: 35 >And in article fpb@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