Newsgroups: comp.sys.sun.admin
Subject: Re: ATTENTION: A problem with dump under 4.1.1
From: agw@math.canterbury.ac.nz (Allen Witt)
Date: 23 Jul 92 13:20:33 +1200
Distribution: world
Organization: Department of Mathematics, University of Canterbury
Keywords: tape, cleaning

 billq@fnal.gov (William R. Quayle) write
>In article <1992Jul21.195006.112389@zeus.calpoly.edu>, etsiao@joule (Eddie Tsiao) writes:
>|> In article <1992Jul20.073110.20195@aristo.tau.ac.il> shani@GENIUS.TAU.AC.IL (Oren Shani) writes:
>|> We have had (are having?) similar problems.  We occationally get an error:
>|> 
>|>   DUMP: Tape write error 753 feet into tape 1
>|>   DUMP: fopen on /dev/tty fails
>|>   DUMP: The ENTIRE dump is aborted.
>|> 
>Sorry if I've missed this in an earlier followup, but has the drive been
>cleaned?  I realize that 8mm cleaning is a sensitive issue (you don't want
>to overdo it or *ever* use video cleaners!), but I encountered these same
>errors on our servers.  After a cleaning with an Excabyte 8mm cleaning
>cartridge, the problems subsided.

I'm having lots of problems dumping to an Exabyte drive here and cleaning
the tape with an Exabyte cleaning cartridge has no effect on the problem.
We dump filesystems overnight, level 0 once a month, level 5 once a week and
level 9 daily unless running a lower level dump, to a drive on a REMOTE 
drive using rdump. The typical problem is the st driver syslogs an error
'write file mark' failed, cause 'media error', the tape is rewound, dump 
has exited without error so the next dump starts from beginning of tape,
overwriting ... Oddly enough, I can step past these using mt and read dumps
further down the tape !!!!!.
Last night this problem occurred again, with a twist. The tape had had one
previous use - 'write file mark' failed on the last dump - been erased ready
for another use. This time 'write file mark' failed on the second dump file,
then the next dump failed with
  DUMP: write: I/O error

  DUMP: write: I/O error

  DUMP: Tape write error 4 feet into tape 1
  DUMP: fopen on /dev/tty fails
  DUMP: The ENTIRE dump is aborted.
****************************************************************
*********** Dump has failed, aborting rest of dump.*************
****************************************************************
Bad tape? Faulty hardware? perhaps.
This morning, however, I logged on to the tape host and tar'd a
150 Mb directory to the same tape ( last night's dump went awry
after ~40Mb ) and was able to retrieve files from the end of the 
tar file without a sign of media problems! On reflection I realised
that I'd never noticed problems with dump on the tapehost - we dump
this occasionally and will include in the cycle when w this problem
is resolved. This suggests to me the problem with dump/Exabytes is
rmt interface/protocol Sun use between rdump and the remote dumphost,
although we never had problems until the drive was more than 4 months
old.
	The question to be answered is - Is this a hardware problem or
a software problem or a firmware problem or an interaction between all
or any two of these? 
	Do sun know of this problem? Have they a patch for it? Is this
why they are promoting upgrades to Exabyte 8500 units ( ours is an 8200)?

-- 

Allen Witt			email:	agw@math.canterbury.ac.nz