RE: gtar failing, please help!
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Bear Sent: Wednesday, February 02, 2005 5:22 PM To: freebsd-questions@freebsd.org Subject: Re: gtar failing, please help! for me, my experience down scsi tape units and freebsd has been a road into the black abyss. I've finally got the tape dumps to work -- but it took many hours of trial and error. btw, I wonder how many tape unit users get burned by the fact that they don't test their tapes -- and when they need the tape find that it was bad.. Probably lots - I always use the compare switch in my tar backup scripts to avoid that. Have you ever had the un-pleasure of working with Sun's tar, though? no compare switch, and the kernel only reports tape block errors to the console. (assuming your lucky enough to have a tapedrive that reports errors back to the kernel that the kernel understands) Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gtar failing, please help!
On Thursday 03 February 2005 01:22, David Bear wrote: snip btw, I wonder how many tape unit users get burned by the fact that they don't test their tapes -- and when they need the tape find that it was bad.. I back up to CDs, and have it md5 the file going onto the CD then md5 it off again. It all happens in the middle of the night so it doesn't bother me that its slow. -- /Xian Aim Low, Reach Your Goals, Avoid Disappointment unknown author ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gtar failing, please help!
On Wed, Feb 02, 2005 at 06:22:21PM -0700, David Bear wrote: since you are using a tape, have you checked with dmesg (for kernel message about the tape) mt errstat (cryptic output, but maybe someone here could help) I get this in my dmesg output: (sa0:ahc0:0:1:0): AutoSense Failed (sa0:ahc0:0:1:0): WRITE FILEMARKS. CDB: 10 0 0 0 2 0 (sa0:ahc0:0:1:0): CAM Status: SCSI Status Error (sa0:ahc0:0:1:0): SCSI Status: Check Condition (sa0:ahc0:0:1:0): ILLEGAL REQUEST asc:24,0 (sa0:ahc0:0:1:0): Invalid field in CDB: Command byte 3 bit 1 is invalid (sa0:ahc0:0:1:0): Unretryable error (sa0:ahc0:0:1:0): failed to write terminating filemark(s) (sa0:ahc0:0:1:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state. Of course, I can't use an OFFLINE, REWIND, or MTEOM command: # mt rewind mt: /dev/nsa0: Invalid argument # mt offline mt: /dev/nsa0: Invalid argument # mt mteom mt: mteom: unknown command # camcontrol reset 2:1:0 Reset of 2:1:0 was successful # mt status Mode Density Blocksize bpi Compression Current: 0x28:X3.224 variable 378710x4 -available modes- 0:0x28:X3.224 variable 378710x4 1:0x28:X3.224 variable 378710x4 2:0x28:X3.224 variable 378710x4 3:0x28:X3.224 variable 378710x4 - Current Driver State: at rest. - File Number: 0 Record Number: 0Residual Count 0 What's funny is that I tried using bsdtar for the same backup used to produce the results above and, although it appears the tar command worked (no error messages on terminal), the tape is inaccessible, just like when I use gtar. This also gets put in dmesg: (sa0:ahc0:0:1:0): AutoSense Failed (sa0:ahc0:0:1:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state. Here are some other dmesg messages that came across during playing with this thing. Do I need to get my tape drive serviced? (sa0:ahc0:0:1:0): parity error detected in Data-in phase. SEQADDR(0x55) SCSIRATE(0x93) (sa0:ahc0:0:1:0): parity error detected in Data-in phase. SEQADDR(0x1a1) SCSIRATE(0x93) (sa0:ahc0:0:1:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state. (sa0:ahc0:0:1:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state. (sa0:ahc0:0:1:0): AutoSense Failed (sa0:ahc0:0:1:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state. Occasionally I can get output from an mt errstat command: 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: 08 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 Last Control Sense: F0 00 08 00 00 20 00 18 00 00 00 00 00 05 00 00 00 00 00 81 00 80 00 1D 0E 00 00 00 0C 00 00 00 This stuff means nothing to me. or rather try dd if=/dev/zero of=/dev/nsa0 bs=512 count=1 then play with different bs and count number. This will show you what your tape block size is -- and if your tape has some kind of crc error at a block, will also stop consistently at the same location. Interestingly enough, I get ZERO errors with this, for any (valid) value for bs or count: # dd if=/dev/zero of=/dev/nsa0 bs=512 count=1 1+0 records in 1+0 records out 512 bytes transferred in 9.709399 secs (527324 bytes/sec) # dd if=/dev/zero of=/dev/nsa0 bs=1024 count=1 1+0 records in 1+0 records out 1024 bytes transferred in 10.987526 secs (931966 bytes/sec) # dd if=/dev/zero of=/dev/nsa0 bs=2048 count=1 1+0 records in 1+0 records out 2048 bytes transferred in 11.537724 secs (1775047 bytes/sec) # dd if=/dev/zero of=/dev/nsa0 bs=4096 count=1 1+0 records in 1+0 records out 4096 bytes transferred in 11.511335 secs (3558232 bytes/sec) # dd if=/dev/zero of=/dev/nsa0 bs=8192 count=1 1+0 records in 1+0 records out 8192 bytes transferred in 11.398908 secs (7186653 bytes/sec) # dd if=/dev/zero of=/dev/nsa0 bs=16384 count=1 1+0 records in 1+0 records out 16384 bytes transferred in 12.226020 secs (13400927 bytes/sec) # dd if=/dev/zero of=/dev/nsa0 bs=32767 count=1 1+0 records in 1+0 records out 32767 bytes transferred in 14.960698 secs (21902053 bytes/sec) # dd if=/dev/zero of=/dev/nsa0 bs=65536 count=1 1+0 records in 1+0 records out 65536 bytes transferred in 18.496691 secs (35431202 bytes/sec) # dd if=/dev/zero of=/dev/nsa0 bs=65536 count=983040 983040+0 records in 983040+0 records out 64424509440 bytes transferred in 1710.457231 secs (37665081 bytes/sec) # mt status Mode Density
Re: gtar failing, please help!
On Wed, Feb 02, 2005 at 02:03:45PM -0500, Kevin A. Pieckiel wrote: I have some backup scripts that manipulate a tape library and tape drive to perform my nightly backups. Ever since the switch from gtar to bsdtar in the base system, gtar fails to write any data to my tape and usually puts my SCSI bus in an unusable state. I must then issue a camcontrol reset command to free up the tape drive for use. Just for grins, I tried playing with dump. Dump fails as well: # dump -0 -a -b 64 -C 32 -f /dev/nsa0 -n -u -L / DUMP: Date of this level 0 dump: Wed Feb 2 14:27:05 2005 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping snapshot of /dev/amrd0s1a (/) to /dev/nsa0 DUMP: mapping (Pass I) [regular files] DUMP: Cache 32 MB, blocksize = 65536 DUMP: mapping (Pass II) [directories] DUMP: estimated 176863 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: write error 64 blocks into volume 1 Broadcast Message from [EMAIL PROTECTED] (/dev/ttyp0) at 14:27 EST... Message from the dump program to all operators DUMP: NEEDS ATTENTION: write error 64 blocks into volume 1 DUMP WRITE ERROR! DUMP: Do you want to restart?: (yes or no) I just don't know what to do. I'm half tempted to use Windows for the fileserver at this point. I *need* working backups! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gtar failing, please help!
On Wed, Feb 02, 2005 at 02:29:26PM -0500, Kevin A. Pieckiel wrote: On Wed, Feb 02, 2005 at 02:03:45PM -0500, Kevin A. Pieckiel wrote: I have some backup scripts that manipulate a tape library and tape drive to perform my nightly backups. Ever since the switch from gtar to bsdtar in the base system, gtar fails to write any data to my tape and usually puts my SCSI bus in an unusable state. I must then issue a camcontrol reset command to free up the tape drive for use. Just for grins, I tried playing with dump. Dump fails as well: # dump -0 -a -b 64 -C 32 -f /dev/nsa0 -n -u -L / since you are using a tape, have you checked with dmesg (for kernel message about the tape) mt errstat (cryptic output, but maybe someone here could help) or rather try dd if=/dev/zero of=/dev/nsa0 bs=512 count=1 then play with different bs and count number. This will show you what your tape block size is -- and if your tape has some kind of crc error at a block, will also stop consistently at the same location. for me, my experience down scsi tape units and freebsd has been a road into the black abyss. I've finally got the tape dumps to work -- but it took many hours of trial and error. btw, I wonder how many tape unit users get burned by the fact that they don't test their tapes -- and when they need the tape find that it was bad.. DUMP: Date of this level 0 dump: Wed Feb 2 14:27:05 2005 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping snapshot of /dev/amrd0s1a (/) to /dev/nsa0 DUMP: mapping (Pass I) [regular files] DUMP: Cache 32 MB, blocksize = 65536 DUMP: mapping (Pass II) [directories] DUMP: estimated 176863 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: write error 64 blocks into volume 1 Broadcast Message from [EMAIL PROTECTED] (/dev/ttyp0) at 14:27 EST... Message from the dump program to all operators DUMP: NEEDS ATTENTION: write error 64 blocks into volume 1 DUMP WRITE ERROR! DUMP: Do you want to restart?: (yes or no) I just don't know what to do. I'm half tempted to use Windows for the fileserver at this point. I *need* working backups! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- David Bear phone: 480-965-8257 fax:480-965-9189 College of Public Programs/ASU Wilson Hall 232 Tempe, AZ 85287-0803 Beware the IP portfolio, everyone will be suspect of trespassing ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
