Path: utzoo!attcan!uunet!cs.utexas.edu!usc!apple!bbn.com!drilex!dricejb From: dricejb@drilex.UUCP (Craig Jackson drilex1) Newsgroups: comp.unix.admin Subject: Re: Dumping to an exabyte tape drive Message-ID: <15493@drilex.UUCP> Date: 13 Sep 90 21:19:32 GMT References: <439@cfa.HARVARD.EDU> <776PKVH@dri.com> Organization: DRI/McGraw-Hill, Lexington, MA Lines: 31 In article <776PKVH@dri.com> braun@dri.com (Kral) writes: >In article <439@cfa.HARVARD.EDU> wyatt@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@drilex.dri.mgh.com {bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}