romeo@lindy.stanford.edu (Patrick Goebel) (07/24/90)
Last week a fellow netlander posted an example of dump parameters to use with an Exabyte: /etc/dump 0fubsd /dev/nrst1 50 6000 54000 /dev/rid000a /etc/dump 5fubsd /dev/nrst1 50 6000 54000 /dev/rid000e /etc/dump 5fubsd /dev/nrst1 50 6000 54000 /dev/rid000f /etc/dump 5fubsd /dev/nrst1 50 6000 54000 /dev/rid000g /etc/dump 5fubsd /dev/nrst1 50 6000 54000 /dev/rid000h /etc/dump 5fubsd /dev/nrst1 50 6000 54000 /dev/rid001e When I use these parameters, the dump program estimates that 136 Mb of files will consume 0.13 tapes. This translates into 1.05 Gb for an entire tape instead of the advertised 2.3 Gb. I'd greatly appreciate knowing the "correct" parameters so that proper capacity estimates are displayed. The density parameter (d) of 54000 is straight out of the Exabyte manual. However, I do not understand the blocking parameter (b) of 50 and the size parameter (s) of 6000. In particular, a 112m Sony 8mm tape is only 367 feet long, not 6000 feet. Also, I suspect there may be a track parameter (t) missing. If anyone knows the answer, posting it to the net might be useful to others as well. Thanks! patrick goebel--romeo@lindy.stanford.edu
jon@uunet.uu.net (Jonathan Yavner) (07/26/90)
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.
matt@oddjob.uchicago.edu (Matt Crawford) (07/30/90)
|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. This can't be true. Every week we dump fourteen partitions to a single tape, and the sum of the sizes is shown in the "used" column of df's output to be 1230727 kB. Looking at the tape, measuring the radii of the hub, the unused portion, and the whole tape, it seems that 2/3 of the tape's length was used. We dump to a local tape with blocks of 100. Maybe that acocunts for the difference somehow, although I don't quite see how. Matt Crawford matt@oddjob.uchicago.edu
poffen@sj.ate.slb.com (Russ Poffenberger) (08/01/90)
In article <1990Jul31.030327.13409@rice.edu> matt@oddjob.uchicago.edu (Matt Crawford) writes: > >|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. > >This can't be true. Every week we dump fourteen partitions to a single >tape, and the sum of the sizes is shown in the "used" column of df's >output to be 1230727 kB. Looking at the tape, measuring the radii of the >hub, the unused portion, and the whole tape, it seems that 2/3 of the >tape's length was used. > >We dump to a local tape with blocks of 100. Maybe that acocunts for the >difference somehow, although I don't quite see how. Keep in mind that EACH file (partition, whatever you want to call it) on an Exabyte tape requires 2Mbytes for the EOF marker. Therefore, if you dump 14 partitions, expect to use 28Mbytes more than you thought. Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen 1601 Technology Drive CIS: 72401,276 San Jose, Ca. 95110 (408)437-5254
shj@uunet.uu.net (Steve Jay) (08/02/90)
We consistantly get about 2.05 GB on 106m Sony (P6-120MP) tapes. We use "dump 0ucfsb /dev/nrst0 120000 126b /partition". The 120000 size is actually too big, and our dumps blow up with write errors at just a little over 2 GB on a tape. We just don't dump more partitions to one tape than we know will fit. Steve Jay shj@ultra.com ...ames!ultra!shj Ultra Network Technologies / 101 Dagget Drive / San Jose, CA 95134 / USA (408) 922-0100 x130 "Home of the 1 Gigabit/Second network"
caxwgk@cs.utexas.edu (Wolfgang G. Kuehnel) (08/02/90)
From article <10198@brazos.Rice.edu>, by romeo@lindy.stanford.edu (Patrick Goebel): > Last week a fellow netlander posted an example of dump parameters to > use with an Exabyte: > /etc/dump 0fubsd /dev/nrst1 50 6000 54000 /dev/rid000a > If anyone knows the answer, posting it to the net might be useful to > others as well. Thanks! We use Exabyte for local dumps of our server machines. Our parameters: /etc/dump 0ucdst 7690 23249 /dev/nrst1 /dev/rxd0a Density and size parameters as recommended by SUN, our Exabyte source. We use SONY tapes, type P5-90 MP and Exabyte cardridges, type 2048. A file of 187.25MB (383478 blocks) dumps to 0.01 tapes, for example. It works fine.