From owner-freebsd-questions Sat Apr 24 18:17:51 1999 Delivered-To: freebsd-questions@freebsd.org Received: from couscous.fortdearborn.com (couscous.fortdearborn.com [204.137.253.195]) by hub.freebsd.org (Postfix) with ESMTP id 3D29B14F4A for ; Sat, 24 Apr 1999 18:17:48 -0700 (PDT) (envelope-from font@couscous.fortdearborn.com) Received: from localhost (font@localhost) by couscous.fortdearborn.com (8.8.8/8.8.8) with SMTP id UAA21513; Sat, 24 Apr 1999 20:17:30 -0500 (CDT) (envelope-from font@couscous.fortdearborn.com) Date: Sat, 24 Apr 1999 20:17:30 -0500 (CDT) From: Font To: freebsd-questions@freebsd.org Cc: dwhite@resnet.uoregon.edu, tinguely@plains.NoDak.edu, carlos@gutierrez.com Subject: UPDATE: DAT always writes short tapes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here's an update on the DAT tape situation. To recap, my WangDAT 3400DX DDS-2 drive errors out after dumping about 1.5 Gbytes of data, whether on a 90m or 120m tape. This is under FreeBSD 3.1-RELEASE. Doug White suggested I use -B and/or -b flags to indicate tape length. Mark Tinguely suggested using the -s and -d flags. Carlos M. Gutierrez suggested ensuring the drive heads were clean. None of these resulted in success. An opportunity arose for me to borrow an Archive Python DDS-2 drive, so I did, and it worked flawlessly (dump -0au /filesys) on the same system. The difference? "mt status" is different. On the WangDAT: lid# mt status Mode Density Blocksize bpi Compression Current: X3B5/88-185A variable 61000 DCLZ ---------available modes--------- 0: X3B5/88-185A variable 61000 DCLZ 1: X3B5/88-185A variable 61000 DCLZ 2: X3B5/88-185A variable 61000 DCLZ 3: X3B5/88-185A variable 61000 DCLZ --------------------------------- Current Driver State: at rest. On the Archive Python: Mode Density Blocksize bpi Compression Current: DDS-2 variable 61000 DCLZ ---------available modes--------- 0: DDS-2 variable 61000 DCLZ 1: DDS-2 variable 61000 DCLZ 2: DDS-2 variable 61000 DCLZ 3: DDS-2 variable 61000 DCLZ --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 0 Record Number: 0 The "Density" is different on the WangDAT. When I tried "mt density DDS-2" on the WangDAT, the command was accepted but it didn't stick; the output of "mt status" was unchanged. I'm assuming the WangDAT's "X3B5/88-185A" just doesn't use any DDS-2 features. However, when I took a 120m tape backed up on the Archive Python and put it into the WangDAT 3400DX, a sample "restore -i" worked just fine. Apparently the WangDAT can detect a properly-formatted tape, it's just hard to get it to write one. Therefore I surmise that either the WangDAT isn't responding to fairly-standard SCSI commands properly, or it's somehow internally broken for writing. So, while I have more information, I still don't know what to do next to get the WangDAT tape drive to work. It seems a shame to put it out to pasture just yet. The only other thing I can think of is to try a backup under Windows (ptui), to see if the drive needs some kind of special support. I may try that tomorrow, with EZ-SCSI, if I have to. And, for the sake of completeness, here's the detect info (only one was attached at any one time, of course): WangDAT: Apr 24 19:39:16 lid /kernel: sa0 at ahc0 bus 0 target 6 lun 0 Apr 24 19:39:16 lid /kernel: sa0: Removable Sequential Access SCSI-2 device Apr 24 19:39:16 lid /kernel: sa0: 5.0MB/s transfers (5.0MHz, offset 15) Archive Python: Apr 24 04:53:52 lid /kernel: sa0 at ahc0 bus 0 target 6 lun 0 Apr 24 04:53:52 lid /kernel: sa0: Removable Sequential Access SCSI-2 device Apr 24 04:53:52 lid /kernel: sa0: 5.0MB/s transfers (5.0MHz, offset 15) Thanks to all who provided suggestions. dw ---------- Forwarded message ---------- Date: Wed, 14 Apr 1999 17:52:43 -0500 (CDT) From: Font To: freebsd-questions@FreeBSD.ORG Subject: DAT always writes short tapes I have a FreeBSD 3.1-RELEASE system with an AHA-2940UW on it, and a WangDAT 3400DX DDS-2 DAT tape drive (along with two 4 gig drives) hung off of it. When I dump to the drive (ie, "dump -0au -f /dev/nrsa0 /home"), dump asks me to change tapes after about 1.5 gigabytes of data has been dumped. Since I use either 90m or 120m tapes, I've been expecting a tape change after more than 2 or more than 4 gigabytes, respectively, depending on the tape. But no matter what size I use, I'm always changing tapes after 1.5 gigabytes. The default compression mode on the drive is DCLZ, according to "mt status". If I turn compression off, or on without using DCLZ, dumps are veerrry slow. The compression switch on the bottom of the drive is on. Other devices on the bus (two SCSI data-only drives) work fine. Is there anything more I should check or fiddle with in FreeBSD before I decide that the drive is broken? In the meantime, I bought a 20 gigabyte EIDE drive to do quicker but less generations of dumps on, but really I'd rather have something I could take offsite. dw To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message