From owner-freebsd-questions  Wed Apr 19 07:48:46 1995
Return-Path: questions-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id HAA20906
          for questions-outgoing; Wed, 19 Apr 1995 07:48:46 -0700
Received: from halon.sybase.com (halon.sybase.com [192.138.151.33])
          by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id HAA20900
          for <questions@freebsd.org>; Wed, 19 Apr 1995 07:48:44 -0700
Received: from sybase.com (sybgate.sybase.com) by halon.sybase.com (5.0/SMI-SVR4/SybFW4.0)
	id AA06392; Wed, 19 Apr 1995 07:49:09 -0700
Received: from red_oak.sybgate.sybase.com by sybase.com (4.1/SMI-4.1/SybH3.4)
	id AA29329; Wed, 19 Apr 95 07:43:35 PDT
Received: by red_oak.sybgate.sybase.com (4.1/SMI-4.1/SybEC3.2)
	id AA10120; Wed, 19 Apr 95 10:43:33 EDT
Date: Wed, 19 Apr 95 10:43:33 EDT
From: jeffa@sybase.com (Jeff Anuszczyk)
Message-Id: <9504191443.AA10120@red_oak.sybgate.sybase.com>
To: obrien@antares.aero.org
Subject: Re: QIC-80 for backups - is this right?
Cc: questions@FreeBSD.org, jeffa@sybase.com
content-length: 1455
Sender: questions-owner@FreeBSD.org
Precedence: bulk

> 	I've got a Colorado Memory QIC-80 "floppy tape" drive,
> which I bought to do backups.  I'm now wondering if it's time to
> sell it and get something else!
> 
> 	I'm trying to get an epochal dump of the root, just to try
> things out.  I'm doing:
> 
> # dump 0fbB - 64 2650 /dev/rsd0a | ft
> 
> 	It's been running for hours.  It steps the tape for quite
> awhile in tiny jerks that I can't believe are really streaming the
> tape, then it'll do a long forward-and-reverse motion, then back
> to tiny jerks.  Is this normal?  Is this an indication that the
> ft0 driver needs serious help?  Should I throw this thing off a pier
> and dump over a thousand bucks into SCSI tape?  What's going on
> here?

Well, personally I've never been a big fan of these tapes drives (I've
definately had problems with them).  However, the problem you describe
sounds a heck of a lot like you hit a bad spot on the tape and the
driver just keeps rewriting over and over.  Are you running V1.1.5.1
or V2.0R?  Version 2 is much better at handling this type of thing...
with V1 the driver had the annoying habit of just sitting there forever
and ever trying to write the tape.

The solution.  Believe it or not I find that reformatting the tape (yup,
spending 2 hours doing it) with the DOS based formatting program (none
available under FreeBSD :-( will generally fix the problem.  This will
reestablish the bad block map and generally set things up pretty well.

- jeff