Dumping to an exabyte tape drive

[Bill Wyatt,OIR]

[...]
>>Basically, dump takes these numbers, multiplies the number of feet by
>>120 to get tenths of inches, munges that some to compensate for
>>interrecord gaps, and multiplies the result by the bytes-per-tenth of
>>inch to get the number of bytes that will fit on the tape. This works
>>fine for cartridge tapes, and 1600 bpi half-inch. Beyond that, life
>>gets bad, for several reasons.
[...]
> So while it is closer there is still a posibility of dump stopping before
> the tape is truly full.  As you can tell from this listing I am getting
> close. I guess I can just bump up the feet a touch more to see what
> happens.  As per Elizabeth [Zwicky] I shall just keep lying until dump 
> finally hears the lie it wants to hear.

Trouble is, if you find the `lie dump wants to hear', it still can't
work reliably, because the (equivalent of) inter-record gaps are
variable length on the Exabyte. If partial track (1 track=8192 bytes)
is written, and more data is not ready, the Exabyte will write the
rest of the tape blank before waiting for more data. Thus, insofar as
the timings for dumps of various files (due to fragmentation, numbers
of files, file lengths, etc.) are unpredictable in detail, the size of
the tape needed is also. 

I can't remember off the top of my head if the Exabyte writes more blank
tracks when data is insufficient. Certainly it eventually, painfully slowly,
stops, backs up and waits for more data before starting up. In any case,
choosing a blocking that's a multiple of 8k will mitigate this loss, so
I can't understand why a blocking factor of 126 (63k) is often recommended.
A blocking factor of 56k=112 should be better.

I think you'd better concede the last 10% or so, as long as dump can't deal
with EOT. And even if it could, I once had a nasty surprise when restore
broke because a multi-volume dump (9-track in this case) did't start at the
beginning of the tape. 

Bill Wyatt, Smithsonian Astrophysical Observatory  (Cambridge, MA, USA)
    UUCP :  {husc6,cmcl2,mit-eddie}!harvard!cfa!wyatt
 Internet:   wyatt at cfa.harvard.edu
     SPAN:   cfa::wyatt                 BITNET: wyatt at cfa