Path: utzoo!attcan!uunet!wuarchive!usc!ucsd!ucbvax!ucsfcgl!babar.mmwb.ucsf.edu!srp From: srp@babar.mmwb.ucsf.edu (Scott R. Presnell) Newsgroups: comp.sys.sgi Subject: Re: Media error on Exabyte Keywords: Exabyte Message-ID: Date: 5 Nov 90 15:19:35 GMT References: <1990Nov2.003444.4650@odin.corp.sgi.com> Sender: daemon@cgl.ucsf.edu Distribution: comp Lines: 38 olson@anchor.esd.sgi.com (Dave Olson) writes: >3) Watch your recovered error rate. I typically see a few hundred > for multi-Mb archives. Whatever your rates are, keep an eye on > them, and clean the heads when the error rate rises, or if you > are trying new tapes, don't use that brand/type if they consistently > return higher error rates. > The recovered errors are reported on close of the tape if the > tape was read or written (or other commands that moved the tape > were used). Typically the counter is reset only when the tape > is unloaded. > Dave Olson I *do* see a few hundred recoverable errors per backup. Since day one. Why is the recovered error rate so high? Or at least why is it so much higher per Mb than the 150Mb QIC drives? Media limitations? or does it have something to do with the driver? There is a cluster of suns here that gets backed up with an exabyte, and that drive doesn't seem to report nearly the error rate that I see. (I think we're talking at least 10:1 sun:SGI). (sorry if that had been covered before). - Scott (srp@cgl.ucsf.edu) >Life would be so much easier if we could just look at the source code. -- But what if we could *hack*, recompile, and execute? -- Scott Presnell +1 (415) 476-9890 Pharm. Chem., S-926 Internet: srp@cgl.ucsf.edu University of California UUCP: ...ucbvax!ucsfcgl!srp San Francisco, CA. 94143-0446 Bitnet: srp@ucsfcgl.bitnet