From owner-freebsd-scsi Mon Oct 6 06:26:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA27509 for freebsd-scsi-outgoing; Mon, 6 Oct 1997 06:26:55 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from stevenson.cogsci.ed.ac.uk (stevenson144.cogsci.ed.ac.uk [129.215.144.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA27488 for ; Mon, 6 Oct 1997 06:26:24 -0700 (PDT) (envelope-from richard@stevenson.cogsci.ed.ac.uk) Received: (from richard@localhost) by stevenson.cogsci.ed.ac.uk (8.8.5/8.8.5) id OAA04524; Mon, 6 Oct 1997 14:26:12 +0100 (BST) Date: Mon, 6 Oct 1997 14:26:12 +0100 (BST) Message-Id: <199710061326.OAA04524@stevenson.cogsci.ed.ac.uk> From: Richard Tobin Subject: Re: Tape Backup To: Philippe Regnauld In-Reply-To: Philippe Regnauld's message of Sun, 5 Oct 1997 22:45:54 +0200 Organization: just say no Cc: freebsd-scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > We're talking about the Travan SCSI HP/Colorado, right ? > > > There was some talk about this drive some time ago, and IIRC, > > > it has a problem with tape locking or something like it There's a harmless error message because the drive doesn't support locking the tape in, and the driver incorrectly doesn't pass SCSI_SILENT or whatever. There was also a problem that they required some bit I forget to be set. I've posted a patch for this several times, but it appears to have been fixed in more recent microcode. Just download the latest microcode from HP and patch it under DOS (yuk). > I thought the T3000 was scsi (travan). SCSI and Travan are orthogonal. I don't know anything about the T3000, it was the T4000s that I had. the "s" means SCSI. > What tape format does the TR-4 use ? TR-4 *is* the tape format, also known as QIC3095. > > Alas, over an ethernet from another FreeBSD 2.2.2 system using dump, > > it hiccuped continuously, getting just about 50KB/second. I used to use a blocksize of 128k, which was fine. However the current dump doesn't allow >64k, and that isn't fine. I know the kernel limits it to 64k, but giving a larger size to dump undeniably made it work better. > > Is there any fix for that, like perhaps a humongous buffer? I figured, > > since the average data rate was 50KB/sec., and the hiccups averaged > > 4 seconds, I was buffering about 200KB. Can I buffer say, 10MB? You could write a trivial C program that buffered as much as you like. HOWEVER, these Travan drives absolutely suck. I've had 3 replacements from HP in two weeks, and *NONE of them work*. -- Richard