tar backup ok but restore errors w/ scsi dat dds2
Ralph Eagle
judge.
Using tar, I can write a tape archive to the scsi dat drive (tar cvf
/dev/st0 /usr/kbmosas) without any errors but when I try to read the tape
back (tar tvf /dev/st0 or tar xvf /dev/st0), I get the following messages
intermingled with the verbose output from tar listing the files in the
archive;
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
tar: Error exit delayed from previous errors
The messages do not seem to be consistent - sometimes the base-64 header
message does not happen and once or twice out of about ten or twenty tries,
I can read the tape back without an error. It seems like the bigger the
backup the more likely the problem. I've put the scsi card and drive in two
other boxes 1) an old SCO box running on a 486DX266 and 2) Debian 3.1
(2.4.18-bf2.4) running on an IBM PC Server (PentiumII) and had no problems.
I'm running the 2.4.18-bf2.4 kernel with an Adaptec AHA-2940UW scsi card and
a Seagate STD28000N drive on a Celeron 2.4GHz box w/ 512MB RAM. The tape
drive is the only scsi device in the system. Here is more info:
tar version: 1.15.1-2
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.4
<Adaptec 2940 Ultra SCSI adapter>
<aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
Vendor: ARCHIVE Model: Python 04687-XXX Rev: 6610
Type: Sequential-Access ANSI SCSI revision: 02
(scsi0:A:6): 7.812MB/s transfers (7.812MHz, offset 15)
st: Version 20020205, bufsize 32768, wrt 30720, max init. bufs 4, s/g segs
16
Attached scsi tape st0 at scsi0, channel 0, id 6, lun 0
st0: Block limits 1 - 16777215 bytes.
st0: Error with sense data: current st09:00: sns=70 5
ASC=26 ASCQ=0
raw sense data: 0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x12 0x00 0x00 0x00 0x00
0x26 0x00 0x00 0x8f 0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x3a 0x6b 0x40
shinzon:~# mt status
drive type = Generic SCSI-2 tape
drive status = 603980288
sense key error = 0
residue count = 0
file number = 0
block number = 0
Tape block size 512 bytes. Density code 0x24 (DDS-2).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN
I've tried what I know... any ideas?
Ralph Eagle
Kubinski Business Systems
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
michael
> judge.
>
> Using tar, I can write a tape archive to the scsi dat drive (tar cvf
> /dev/st0 /usr/kbmosas) without any errors but when I try to read the tape
> back (tar tvf /dev/st0 or tar xvf /dev/st0), I get the following
> messages
> intermingled with the verbose output from tar listing the files in the
> archive;
>
> tar: Skipping to next header
> tar: Archive contains obsolescent base-64 headers
> tar: Error exit delayed from previous errors
>
> The messages do not seem to be consistent - sometimes the base-64 header
> message does not happen and once or twice out of about ten or twenty
> tries,
> I can read the tape back without an error. It seems like the bigger the
> backup the more likely the problem.
you're not hitting the 2Gb limit (with some tar) are you?
Alvin Oga
On Tue, 27 Sep 2005, michael wrote:
> > I think this might be a hardware compatibility problem, but you be the
> > judge.
> >
> > Using tar, I can write a tape archive to the scsi dat drive (tar cvf
> > /dev/st0 /usr/kbmosas) without any errors but when I try to read the tape
> > back (tar tvf /dev/st0 or tar xvf /dev/st0), I get the following
> > messages
> > intermingled with the verbose output from tar listing the files in the
> > archive;
> >
> > tar: Skipping to next header
means the tape was jumping around waiting for your system or ..
> > tar: Archive contains obsolescent base-64 headers
> > tar: Error exit delayed from previous errors
your tape is bad .. and/or clean the head ...
and/or when writing ..
find /home/kbmosas | buffer | tar cvf /dev/st0
c ya
alvin
Ralph Eagle
> you're not hitting the 2Gb limit (with some tar) are you?
>
Nope... while trying to debug the problem, I've been using groups of files
in the 2 to 10 MB range. And, when I put the card and tape drive into the
other boxes (SCO 486 and Linux PII) I used the same set of data for testing.
Ralph Eagle
>
> means the tape was jumping around waiting for your system or ..
>
>> > tar: Archive contains obsolescent base-64 headers
>> > tar: Error exit delayed from previous errors
>
> your tape is bad .. and/or clean the head ...
>
problem and tape cleaning came up a fair number of times. I have cleaned the
drive with a cleaning cart. When I put the scsi card and tape drive into the
other boxes (SCO 486/Linux PII) I used the same tape, and the same set of
backup files for my tests - experienced no problem
I think this might be some type of conflict with the mobo perhaps?
> and/or when writing ..
> find /home/kbmosas | buffer | tar cvf /dev/st0
Hmmm, can not seem to get the above command to work. Produces the following
error:
tar: Cowardly refusing to create an empty archive
Try `tar --help' or `tar --usage' for more information.
Looked at the buffer man page and tried several permutations of your command
but could not get it to work. Besides it looks like buffer will only help
writing the data to the tape... The problem I have is reading the data back
off the tape. When I create the tar archive using: tar cvf /dev/st0
/usr/kbmosas there are no errors reported by tar. The problem is trying to
read the data back from the archive just made.
> c ya
> alvin
Ralph Eagle
Kubinski Business Systems
Alvin Oga
hi ya eagle
On Tue, 27 Sep 2005, Ralph Eagle wrote:
> > and/or when writing ..
> > find /home/kbmosas | buffer | tar cvf /dev/st0
>
> Hmmm, can not seem to get the above command to work. Produces the following
> error:
> tar: Cowardly refusing to create an empty archive
> Try `tar --help' or `tar --usage' for more information.
welll.. what does the message say ??
- moreimportantly, do NOT type commands and hints people
post in the list w/o knowing what it will do
- i assume you know to add the right options to find
- i assume you know to go find the program called buffer
- i assume you know the options for tar to read from stdin
( does "tar cvf /dev/std0 -" help ?? or
( even "tar cvf /dev/std0 -T -" or
( lots of other permutations
yeah.. yeah about "assume" ...
> Looked at the buffer man page and tried several permutations of your command
> but could not get it to work. Besides it looks like buffer will only help
> writing the data to the tape... The problem I have is reading the data back
> off the tape.
if its written wrong ... it will barf at reading
it's written wrong if you do NOT hear a constant whine of the tape
vs the stop/rewind/start noises
> When I create the tar archive using: tar cvf /dev/st0
> /usr/kbmosas there are no errors reported by tar. The problem is trying to
> read the data back from the archive just made.
of course not... and do you know why not ..
and that doesnt solve the problem of maybe the data is nto written
as you expected due to other problems
- what kind of tape noises does it make when its writing
and it should be a nice and steady/constant whine ...
c ya
alvin
Ralph Eagle
> post in the list w/o knowing what it will do
> - i assume you know to add the right options to find
> - i assume you know to go find the program called buffer
> - i assume you know the options for tar to read from stdin
Yes, Yes and Yes
I've worked with SCO Xenix/Unix, Novell Unixware, Slackware/Red Hat/Debian
Linux, Solaris, and AIX over 14 years. But I don't claim to be a guru -
that's why I came to the list for help after trying everything I knew. We
use tape backup on all our in-house and customer's systems and have never
run into this problem.
> yeah.. yeah about "assume" ...
lol...
>> ... Besides it looks like buffer will only help
>> writing the data to the tape... The problem I have is reading the data
>> back
>> off the tape.
>
> if its written wrong ... it will barf at reading
Excellent point.
I assumed that if there was a problem writing the data I would get an error.
yeah.. yeah about "assume" ... lol
>> When I create the tar archive using: tar cvf /dev/st0
>> /usr/kbmosas there are no errors reported by tar. The problem is trying
>> to
>> read the data back from the archive just made.
>
> of course not... and do you know why not ..
:( -- more scolding -- :(
> and that doesnt solve the problem of maybe the data is nto written
> as you expected due to other problems
> - what kind of tape noises does it make when its writing
> and it should be a nice and steady/constant whine ...
Sounds normal to me - although it is a DAT drive and pretty quiet, not like
the old QIC 1/4in or Travan drives.
I think I've exhausted my resources attacking this from the software side.
Will do a little mobo swap and see what happens.
> c ya
> alvin
Thanks for your help Alvin
Ralph Eagle
Kubinski Business Systems
Alvin Oga
hi ya ralph
On Wed, 28 Sep 2005, Ralph Eagle wrote:
> > - moreimportantly, do NOT type commands and hints people
> > post in the list w/o knowing what it will do
> :( -- feeling like a scolded step child now... :(
:-) ... just watching out for ya... to not cut-n-paste commands
but couldn;t resist that initial comment
> > of course not... and do you know why not ..
> :( -- more scolding -- :(
so try to copy stuff to tape, again ...
find /home/ralph | buffer | tar zcvf /dev/st0 -T -
should sound nice and smooth .. no stopping and starting
- it should be a constant and steady whine
> I think I've exhausted my resources attacking this from the software side.
> Will do a little mobo swap and see what happens.
yeah.. but first get the tar command and buffer right...
than spend some dough on a better mb, but no guarantee to fix
the original problem
- get a new tape cleaner and new tape
- try a different tape drive
- make sure you have enough cpu hp
- make sure yu have enough memory
- ( top -i ) should be almost no load while writing to tapes
c ya
alvin
Alvin Oga
On Wed, 28 Sep 2005, Ralph Eagle wrote:
> shinzon:~# find /usr/kbmosas/std | buffer | tar zcvf /dev/st0 -T -
> Backed up 110 files, 1.2MB without any errors from tar
...
> shinzon:~# tar tzvf /dev/st0
> drwxrws--- root/users 0 2005-08-25 10:10:35 usr/kbmosas/std/
> -rw-rw---- root/users 7516 2005-08-25 10:31:52 usr/kbmosas/std/_amort
> tar: Skipping to next header
> tar: Archive contains obsolescent base-64 headers
>
> gzip: stdin: invalid compressed data--format violated
> tar: Child died with signal 13
> tar: Error exit delayed from previous errors
sounds like youhave:
- bad motherboard/memory
- bad tape drive cables
- do NOT put a tape drives on the same (ide) cables as disks
- do NOT put disk ond cdrom/dvd on the same (ide) cables
- which scsi card ..
- i'd always be using the latest kernel to 2.4.31 or 2.6.13 for the
latest drivers at the first sign of something broken
and going down to latest gcc/glibc/bash if needed
> Tested writing/reading tar ball to hd with no problem
good ansity check
> And there is the fact that if I put this
> scsi card and either tape drive in another box (tried two other 1- SCO Unix
> on a 486DX266 and 2- Debian Linux on a PII in testing), they work fine.
good .. hw might be okay with the distro you ran the test with
> This all leads me to think that the problem is the environment (mobo). Maybe
> this particular combination of mobo/scsi?
yup or memory that wasn't used in the previous tests
Ralph Eagle
>
> find /home/ralph | buffer | tar zcvf /dev/st0 -T -
>
> should sound nice and smooth .. no stopping and starting
> - it should be a constant and steady whine
>> I think I've exhausted my resources attacking this from the software
>> side.
>> Will do a little mobo swap and see what happens.
>
> yeah.. but first get the tar command and buffer right...
> than spend some dough on a better mb, but no guarantee to fix
> the original problem
> - get a new tape cleaner and new tape
> - try a different tape drive
> - make sure you have enough cpu hp
> - make sure yu have enough memory
> - ( top -i ) should be almost no load while writing to tapes
> c ya
> alvin
I tried it one more time...
Cleaned the drive with a new cleaning cart and used a new tape.
I was the only user logged on the box and top -i showed CPU 99.7% idle
Running a Celeron 2.4GHz w/ 512MB RAM
Ran the tar through buffer:
shinzon:~# find /usr/kbmosas/std | buffer | tar zcvf /dev/st0 -T -
tar: Removing leading `/' from member names
/usr/kbmosas/std/
/usr/kbmosas/std/_amort
/usr/kbmosas/std/_ascii
/usr/kbmosas/std/_browse
...
/usr/kbmosas/std/_label
/usr/kbmosas/std/_qres
/usr/kbmosas/std/_xkey.utl
Backed up 110 files, 1.2MB without any errors from tar
ok, now read the tape back:
shinzon:~# tar tzvf /dev/st0
drwxrws--- root/users 0 2005-08-25 10:10:35 usr/kbmosas/std/
-rw-rw---- root/users 7516 2005-08-25 10:31:52 usr/kbmosas/std/_amort
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
gzip: stdin: invalid compressed data--format violated
tar: Child died with signal 13
tar: Error exit delayed from previous errors
= barfd
I have already tried two different tape drives (seagate/sony), different
tapes, cleaned the drive repeatedly, flashed bios on scsi with latest ver,
updated tar to 1.15.1-2, and now tried buffer(ing). Tested writing/reading
tar ball to hd with no problem. And there is the fact that if I put this
scsi card and either tape drive in another box (tried two other 1- SCO Unix
on a 486DX266 and 2- Debian Linux on a PII in testing), they work fine.
This all leads me to think that the problem is the environment (mobo). Maybe
this particular combination of mobo/scsi?
I'll let you know what happens.
Ralph Eagle
Kubinski Business Systems
--
Frank Gevaerts
> Ran the tar through buffer:
Yes, but you didn't give tar an output block size.
> shinzon:~# find /usr/kbmosas/std | buffer | tar zcvf /dev/st0 -T -
Try:
mt -f /dev/st0 setblk 32768
find /usr/kbmosas/std | tar zcvf /dev/st0 -T -b 64 -
(if the drive doesn't accept 32768, try 16384, and -b 32 with tar)
That way, the tape drive and tar both use the same blocksize.
Frank
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
Simo Kauppi
I had a similar problem with tar a while ago. I wasn't using scsi though
but just backing up files to CD and DVD. Reading the archives gave me
errors, but I can't remember if they were exactly the same as yours.
Memory test (compiling xorg :) revealed a memory problem which turned
out to be just badly installed memory module. Reinstalling the modules
solved my problem and all was fine after that.
Simo
--
:r ~/.signature
Ralph Eagle
> Yes, but you didn't give tar an output block size.
>> shinzon:~# find /usr/kbmosas/std | buffer | tar zcvf /dev/st0 -T -
> Try:
> mt -f /dev/st0 setblk 32768
> find /usr/kbmosas/std | tar zcvf /dev/st0 -T -b 64 -
Ok - here's what I got:
ran this -
shinzon:~# mt -f /dev/st0 setblk 32768
shinzon:~# find /usr/kbmosas/std | tar zcvbf 64 /dev/st0 -T -
tar finished without error 110 files, 1.2MB
Now, read it back and BAM:
shinzon:~# tar tzvbf 64 /dev/st0
incomplete literal tree
drwxrws--- root/users 0 2005-08-25 10:10:35 usr/kbmosas/std/
-rw-rw---- root/users 7516 2005-08-25 10:31:52 usr/kbmosas/std/_amort
-rw-rw---- root/users 5872 2005-08-25 10:31:52 usr/kbmosas/std/_ascii
-rw-rw---- root/users 2127 2005-08-25 10:31:52 usr/kbmosas/std/_browse
-rw-rw---- root/users 6494 2005-08-25 10:31:52 usr/kbmosas/std/_bundle
-rw-rw---- root/users 8624 2005-08-25 10:31:52 usr/kbmosas/std/_calc
gzip: stdin: invalid compressed data--format violated
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
> That way, the tape drive and tar both use the same blocksize.
>
> Frank
Good try Frank, thanks for the input - I really think I'm dealing with a
hardware issue.
Ralph Eagle
Kubinski Business Systems
Mike McCarty
[snip]
> - do NOT put a tape drives on the same (ide) cables as disks
> - do NOT put disk ond cdrom/dvd on the same (ide) cables
[snip]
Umm, why not put hard disc and CDROM drive on same ATA cable?
I agree that it is bad practice to make a hard disc a slave to
a CDROM drive, but the other way 'round is IMO the preferred method
for connecting them. IOW, I have two ATA interfaces on my MB, and
I have four drives. Each controller has one hard disc and one CDROM
drive. This permits multiple seeks to be issued. Putting both
hard discs on one controller would result in reduced throughput
(to/from the hard discs).
What is your reasoning?
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
Alvin Oga
On Wed, 28 Sep 2005, Ralph Eagle wrote:
> shinzon:~# mt -f /dev/st0 setblk 32768
> shinzon:~# find /usr/kbmosas/std | tar zcvbf 64 /dev/st0 -T -
...
> shinzon:~# tar tzvbf 64 /dev/st0
> incomplete literal tree
...
> gzip: stdin: invalid compressed data--format violated
> tar: Unexpected EOF in archive
...
> Good try Frank, thanks for the input - I really think I'm dealing with a
> hardware issue.
yup... take the drive and controller and system disk to a different
motherboard, ps and memory and see what breaks
i think your powersupply is dying ...
c ya
alvin
Alvin Oga
On Wed, 28 Sep 2005, Mike McCarty wrote:
> Alvin Oga wrote:
>
> [snip]
>
> > - do NOT put a tape drives on the same (ide) cables as disks
> > - do NOT put disk ond cdrom/dvd on the same (ide) cables
>
> [snip]
>
> Umm, why not put hard disc and CDROM drive on same ATA cable?
cdroms are typically ata-33
disks are typically ata-100 or ata-133
- the timing on the cable is different sized signals ( pulse
widths ) and different loads/terminations... blah.. blah...
whenver the disks does stuff ... it will try to talk at 133MB/sec
and if the cdrom is smart enough, it'd will say, hey
w----h----a----a----b----o----u----t slowing down the disk,
which the system says go away, it aint for you ( cdrom )
slowly releasing the disk interrupt again
> I agree that it is bad practice to make a hard disc a slave to
> a CDROM drive
ever wonder why that was dell's decault config for some systems ??
where cdrom is hda and disk is hdb
c ya
alvin
Ken Walker
system as a black hole, it's a serial stream rather than a file system. Your
only limit is the capacity of the drive.
:o)
> -----Original Message-----
> From: Ralph Eagle [mailto:ra...@kubinski.com]
> Sent: 27 September 2005 2:28pm
> To: debia...@lists.debian.org
> Subject: Re: tar backup ok but restore errors w/ scsi dat dds2
>
>
> >
> > you're not hitting the 2Gb limit (with some tar) are you?
> >
>
> Nope... while trying to debug the problem, I've been using
> groups of files
> in the 2 to 10 MB range. And, when I put the card and tape
> drive into the
> other boxes (SCO 486 and Linux PII) I used the same set of
> data for testing.
>
>
Ralph Eagle
Thanks for all the good input from everyone. Nice to know you are all there
in time of need (even if we couldn't solve the problem from the software
side).
I swapped out the mobo, went from an AOpen MX46VG(E) to an AOpen AX4SPE-UN.
Same CPU, RAM, NIC, SCSI, DAT - went from on board video to a GeForce MX4000
8x AGP.
Said the magic word: Abra-ca-pocus! and the problem dissapeared.