Dumping to an exabyte tape drive

[Elizabeth Zwicky]

In article <877 at iiasa.UUCP> wnp at iiasa.UUCP (wolf paul) writes:
>These figures seem quite inconsisten. Which is correct?
>Would someone at SUN care to comment, ideally the person who wrote
>their drivers?

>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

OK, so I don't work for Sun and I didn't write their drivers, but
since this actually has nothing to do with Sun's generic SCSI driver,
that's probably just as well.

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.

1) Dump does not ever actually check for EOT; it believes that tapes
are the length it calculates, and attempts to write that much. If
that's more than will fit, you will get a write error.

2) Dump's concept of how to munge the number of feet in the tape to
compensate for interrecord gaps is pitifully inaccurate. By the time
you get to 6250 bpi tape, you are already putting enough on the tape
that the accumulated error mounts up. Thus, people with 6250 bpi tape
drives frequently end up having to claim that 2500 foot tapes are
really only 2300 feet long in order to keep dump from writing off the
end. On an exabyte, the error is even more significant.

3) Dump doesn't allocate enough space internally to cope with the
genuine density of an exabyte; nobody thought tapes would get that
dense at the time. 

So part of the trouble here is that telling dump the truth won't work,
several times over; dump can't cope with the truth, and even if it
could, its idea of an interrecord gap is wildly off and so it would
get wrong how many could fit. So why do people use different lies?
Different blocking factors; different device drivers; different
versions of dump (OSU's fast dump redoes the interrecord gap
calculations and bumps the shorts to ints and the ints to longs,
bypassing problems 2) and 3)); different guesses, for that matter. As
long as your largest filesystem is smaller than an exabyte, and also
small enough that dump thinks it will fit, it really doesn't matter.
If it won't fit, play with the parameters...

	Elizabeth Zwicky