Dumping to an exabyte tape drive

[Craig Jackson drilex1]

In article <776PKVH at dri.com> braun at dri.com (Kral) writes:
>In article <439 at cfa.HARVARD.EDU> wyatt at cfa.HARVARD.EDU (Bill Wyatt,OIR) writes:
>>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. 
>
>So the $64k question now is: why can't dump properly deal with end of tape?
>It's not like it's a new technology or something.

The traditional reason why Unix programs do not deal properly with end-of-tape
is because Unix tape drivers do not deal properly with end-of-tape.
The problem is that end-of-tape is reported as an error indication on
a write; frequently, the same block can later be read with no error
indication.  (This is an issue in the design of the driver; if tape
interchange is an issue, it is an issue in the design of all relevant
drivers.)

I think that cartridge tapes may be different than nine-track drives in
this regard.

(There is a separate problem with Unix tape drivers and end-of-tape;
ANSI labels require writing several records *after* the tape mark is
seen, and the block over the mark is valid.   However, this is not an
issue for dump, which does not use ANSI labels.)

(The above comment brought to you by the new-text vs included-text rules.)
-- 
Craig Jackson
dricejb at drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}