rowe@cme.nist.gov (Walter Rowe) (09/07/90)
>>>>> On 4 Sep 90 17:02:28 GMT, rsb1@cbnewsk.att.com (richard.s.brown) said: |> We use 120 min tapes. We bought our drives from Perfect Byte, |> Inc. in Omaha, Nebraska. The documentation we received was |> remarkably good (and concise!) Here are the suggested values for |> 'dump': |> Blocking factor: 126 |> Density: 54000 (bpi!!!) |> Length: 6000 (ft.) |> I hope this helps! |> Rich Brown |> AT&T Network Systems |> rsb@vogon.att.com Exactly the same here, including the vendor! wpr --- Walter P. Rowe ARPA: rowe@cme.nist.gov System Administrator, Robot Systems Division UUCP: uunet!cme-durer!rowe National Institute of Standards and Technology LIVE: (301) 975-3694
dave@imax.com (Dave Martindale) (09/11/90)
On 4 Sep 90 17:02:28 GMT, rsb1@cbnewsk.att.com (richard.s.brown) said: > We use 120 min tapes. We bought our drives from Perfect Byte, > Inc. in Omaha, Nebraska. The documentation we received was > remarkably good (and concise!) Here are the suggested values for > 'dump': > Blocking factor: 126 > Density: 54000 (bpi!!!) > Length: 6000 (ft.) Yes, that's what the Perfect Byte manual says, but they're wrong. The blocking factor is fine; 126 (512-byte) blocks is the largest transfer you can do to an Exabyte on a Sun and still have the block size a multiple of 1024. (1024 bytes is the Exabyte's own internal block size). However, the density and length figures, when multiplied together, tell "dump" that you can fit 3.8 Gb on a tape. Dump will reduce that somewhat by allowing for inter-record gaps (which are nonexistent on 8mm tape), but I think you'll find that dump will hit the Exabyte's end-of-tape while it thinks there is more tape left. Now, if all of your dumps will fit on one Exabyte tape anyway, this is fine - all you really have to do is convince dump that the tape is bigger than the amount of data that is to go on it. However, if you have enough data to take more than one tape, you'll have to calculate the real size of the tape more accurately.