Date: Wed, 17 Jan 2007 21:44:12 -0600 (CST) From: User SKIP <skip@rc.tex-an.net> To: freebsd-bugs@FreeBSD.org Cc: mjacob@FreeBSD.org, bdluevel@heitec.net Subject: bin/106973: 'tar' cannot read own tape, but 'pax' can Message-ID: <20070117213228.Y686@rc.tex-an.net>
next in thread | raw e-mail | index | archive | help
-------------------------------------------------------------------------------- Any info on the "works with pax, won't work with tar" problem? I have a "Python" DDS4 tape drive from a Dell PowerEdge 1400SC, model number "STD2401LW". Under 6.2-RELEASE, I am not able to successfully read any tapes with tar. They seem to be written correctly, since I can read them OK with pax, but tar won't read them. I've tried setting the block size to "2" and to various other sizes. I think a block size of 2 DID work on 6.2RC1. This isn't a production system, so I can run any tests that are needed. I have tested with the EOT model set at both 1 and 2. One of the tests generated 100 lines of SCSI complaints, but I am hesitant to thrash the drive again to see which test caused that. The error messages are at the site listed below. Below is an edited capture of the results when using a block size of 2 for both the write and the (attempted) read. Complete dmesg.boot, camcontrol output, and various tar tests with the full scripts and logs are at: http://www.math.austin.tx.us:/dds4-drive Let me know what else I should test. *********** # uname -a FreeBSD frak.math.austin.tx.us 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Tue Jan 16 12:59:10 CST 2007 root@frak.math.austin.tx.us:/usr/obj/usr/src/sys/FRAK i386 # dmesg | grep -i sa0 | grep -v isa0 sa0 at ahc1 bus 0 target 6 lun 0 sa0: <ARCHIVE Python 06408-XXX 9100> Removable Sequential Access SCSI-3 device sa0: 40.000MB/s transfers (20.000MHz, offset 32, 16bit) # mt geteotmodel /dev/nsa0: the model is 2 filemarks at EOT # mt status Mode Density Blocksize bpi Compression Current: 0x26:DDS-4 1024 bytes 97000 DCLZ ---------available modes--------- 0: 0x26:DDS-4 1024 bytes 97000 DCLZ 1: 0x26:DDS-4 1024 bytes 97000 DCLZ 2: 0x26:DDS-4 1024 bytes 97000 DCLZ 3: 0x26:DDS-4 1024 bytes 97000 DCLZ --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 0 Record Number: 0 Residual Count 0 # tar -cvb 2 -f /dev/nsa0 usr/bin [ normal tar creation output ] # tar -tvb 2 -f /dev/nsa0 drwxr-xr-x 0 root wheel 0 Jan 16 16:43 usr/bin -r-xr-xr-x 0 root wheel 61788 Jan 16 16:41 usr/bin/bc tar: Unrecognized archive format: Inappropriate file type or format # mt errstat Last I/O Residual: 0 Last I/O Command: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Last I/O Sense: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Last Control Residual: 0 Last Control Command: 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Last Control Sense: 70 00 06 00 00 00 00 0A 00 00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # > I would expect a Travan based drive to be like a QIC tape. From my > minimal experience with them, they seem to be derived from QIC standards > and probably derive from native QIC-02 starting back 20 odd years ago > (like the old Cipher Floppy-Tape drive which had an SA850 interface). > I dunno why tar didn't give a 0 exit on the create, but try again > replacing the || with ; > The point here is to try and force 512 and 1024 byte record creation and > to force 512 and 1024 byte reads. >> Sure. I would have expected the eotmodel to be 2, but it appears to >> have been 1 to begin with. In order to keep the mail to a sensible >> length, I deleted most of tar's output and replaced it with "[...]". >> However, I don't quite understand the point of this test, since the >> "tar c" _does_ work fine; it's the reading that doesn't work. [...]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070117213228.Y686>