From owner-freebsd-scsi Mon Jul 7 17:34:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA17670 for freebsd-scsi-outgoing; Mon, 7 Jul 1997 17:34:10 -0700 (PDT) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA17665 for ; Mon, 7 Jul 1997 17:34:07 -0700 (PDT) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id RAA22214; Mon, 7 Jul 1997 17:33:52 -0700 (PDT) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id RAA09389; Mon, 7 Jul 1997 17:33:51 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id RAA09068; Mon, 7 Jul 1997 17:33:45 -0700 (PDT) From: Don Lewis Message-Id: <199707080033.RAA09068@salsa.gv.tsc.tdk.com> Date: Mon, 7 Jul 1997 17:33:45 -0700 In-Reply-To: Keith Mitchell "Re: Archive Viper and 3940UW (bad Drive?)" (Jul 5, 9:06pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Keith Mitchell , gibbs@plutotech.com (Justin T. Gibbs) Subject: Re: Archive Viper and 3940UW (bad Drive?) Cc: scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Jul 5, 9:06pm, Keith Mitchell wrote: } Subject: Re: Archive Viper and 3940UW (bad Drive?) } > You shouldn't have to erase used tapes before using them either. } } OK, that is what I thought originally, but then given that erasing them } "seemingly" solved the timeout problem I don't know what to think. What } does erasing a tape actually do? It doesn't take but a few seconds. My } guess is it basically erases the header info that says there is data there, } but I really don't know. } } > If the tape drive needs to look at the media before it can respond, then } > the .5s timeouts are way too short. I've got some type of QIC-150 drive on a Sun, and it seems to require several attempts to figure out the tape format or align its tape head or whatever when it first tries to read a newly inserted tape. It definitely grinds and groans for quite a while. This could be a problem when used with Amanda, since Amanda always wants to read the tape to check the label before it overwrites the tape. I suspect that erasing the tape might speed things up since the drive may be able to quickly detect that the tape is blank. When the tape is used the next time, it may still respond faster since either the data format on the tape may match the drive's expected "probe" order or the head alignment might be better matched to the tape. I'm suprised that you see the erase operation only take a few seconds. It's been my experience that these drives make one full pass through the tape with the erase head turned on, which erases all the serpentine tracks in parallel. FYI, the SunOS st driver defaults to a 2 minute I/O timeout and a 60 minute space timeout. I had to increase the I/O timeout to 10 minutes in order to reliably use a HP1553 DAT drive that occasionally decides to do a head scrub if its error rate starts getting too high. --- Truck