Bug 86081 - amrecover/amrestore fail to read tape properly
Summary: amrecover/amrestore fail to read tape properly
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: amanda
Version: 8.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jay Fenlason
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-03-13 17:35 UTC by Kevin Range
Modified: 2014-08-31 23:24 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-10-18 16:24:06 UTC
Embargoed:


Attachments (Terms of Use)

Description Kevin Range 2003-03-13 17:35:23 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
Attepting to read backup images off a tape with amrecover/amrestore fails with:

amrestore: error reading file header: Input/output error

Version-Release number of selected component (if applicable):
2.4.2p2-9

How reproducible:
Always

Steps to Reproduce:
1. Make a backup with amanda (eveuything will be reported as A-OK)
2. Try to read the tape the next day:

[root@riesling holding_disk]# mt -f /dev/nst0 rewind
[root@riesling holding_disk]# amrestore /dev/nst0 

    

Actual Results:  amrestore:   0: skipping start of tape: date 20030216 label
yorkgroup05
amrestore: error reading file header: Input/output error

Expected Results:  A bunch of amanda dumps should be on my holoding disk from
the tape.

Additional info:

I did find a temporary work around that may also offer some insight into what is
wrong here.  (Thanks to robin on amanda-users for posting this):


$ amadmin config info host drive

Take note of the tape and file number of the data you want.  With the proper
tape in the drive:

$ mt -f /dev/nst0 rewind; mt -f /dev/nst0 fsf filemarker
$ dd if=/dev/nst0 skip1 bs=32k of=backup.tar.gz

And viola, your backup is now sitting on your disk as a tar file, just like
amrecover/amrestore should have been able to do.

So, this work around gives us several important pieces of data.

1. amdump works.
2. the tapes/tape drive are/is good.
3. when doing the dd, an interesting message is printed:

dd: warning: working around lseek kernel bug for file (/dev/nst0)
  of mt_type=0x72 -- see <sys/mtio.h> for the list of types

Is there some kernel bug (2.4.19) that dd knows about, but amrestore does not?

Comment 1 Jay Fenlason 2003-04-21 15:05:16 UTC
lseek() has never worked on tape drives.  Amanda knows this.  dd didn't know
that until it tried to use it to skip forward.

I'm investigating the problem on an Itanium system using a Sony AIT-2 drive.  If
I run amrecover immediately after putting a tape in the drive, it fails.  If I
do a "dd bs=32k < /dev/st0 > /tmp/tapelabel" after I insert the tape but before
I run amrecover, it works fine.  So I suspect a tape device driver problem.

What kind of tape drive are you using.  The problem is probably specific to
certain tape drives.

Comment 2 Kevin Range 2003-04-21 15:34:42 UTC
I am using an external SCSI VXA-1 drive.  Strangely enough, the drive died of a
bad power supply capacitor shortly after I made this report.  The replacement
drive has not shown this problem yet.  So it could have been a hardware thing. 
But I can read all of my old tapes (written with the "bad" drive).  I will try
to read the tape that was written before the failure tomorrow (I just got it
back from Exabyte today in the mail).  If I have any luck in reproducing this
with my new drive I will let you know.

Thanks.

Comment 3 Kevin Range 2003-04-23 19:18:10 UTC
I just reproduced this bug with the replacement drive.  (It is almost like it
knows when I am testing it...  This time we were restoring for real and we had
to use the magic trick above to get the data off the tape.)

Are you sure Amanda knows that lseek is broken?  If it does, why can't it
compensate like dd does?



Comment 4 Bill Nottingham 2006-08-07 19:00:46 UTC
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Red Hat apologizes that these issues have not been resolved yet. We do
want to make sure that no important bugs slip through the cracks.
Please check if this issue is still present in a current Fedora Core
release. If so, please change the product and version to match, and
check the box indicating that the requested information has been
provided. Note that any bug still open against Red Hat Linux on will be
closed as 'CANTFIX' on September 30, 2006. Thanks again for your help.

Comment 5 Bill Nottingham 2006-10-18 16:24:06 UTC
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Closing as CANTFIX.


Note You need to log in before you can comment on or make changes to this bug.