Date: Sat, 24 Apr 1999 20:17:30 -0500 (CDT) From: Font <font@couscous.fortdearborn.com> 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: <Pine.BSF.3.96.990424195956.21445A-100000@couscous.fortdearborn.com>
next in thread | raw e-mail | index | archive | help
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: <WangDAT Model 3400DX 1.1j> 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: <ARCHIVE Python 00367-XXX 5.23> 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 <font@couscous.fortdearborn.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990424195956.21445A-100000>