Hello,

I'm having a strange problem with amrestore.  I get an I/O error in the
middle of a restore and amrestore exits, but st0 device remains busy and
only a reboot can clear it.  There is an error on the console as
follows...

st0: Error 70002 (sugg. bt 0x0, driver bt 0x0, host bt 0x7)

... My first thoughts were hardware errors, but I've checked out
everything I can (short of buying a new library!) and everything seems
fine.  Perhaps more revealingly I have no issues performing backups with
amanda or extracting data from the tape using dd.

Heres the amidxtaped.debug file (I originally experienced the problem
while using amrecover)

###### START amidxtaped.debug [extract] ########

amidxtaped: time 6.803: Ready to execv amrestore with:
path = /usr/local/sbin/amrestore
argv[0] = "amrestore"
argv[1] = "-p"
argv[2] = "-h"
argv[3] = "-l"
argv[4] = "UnixDaily-FHH545"
argv[5] = "-f"
argv[6] = "72"
argv[7] = "/dev/nst0l"
argv[8] = "^myhost.mydomain.com$"
argv[9] = "^/export/home$"
argv[10] = "20050219"
amrestore:  72: restoring myhost.mydomain.com._export_home.20050219.0
amrestore: read error: Input/output error
amidxtaped: time 38.951: amrestore terminated normally with status: 2
amidxtaped: time 38.951: rewinding tape ...

gzip: stdin: unexpected end of file

####### END ######

Running the amrestore command manually (redirecting output to a file)
gives the same errors.  The command was...

amrestore -p -h -l UnixDaily-FHH545 -f 72 /dev/nst0l
^myhost.mydomain.com$ ^/export/home$ 20050219 >  1-amrestore-fromtape

The resulting output file is indeed smaller than expected.

Then...
mt -f /dev/nst0l rewind
my -f /dev/nst0l fsf 72
dd if=/dev/nst0l of=2-dd-fromtape bs=4194304               [My tape
block size is 4096k]

...results in the full file being copied from disk with no errors.  I
can then extract the dump from the file with amrestore...

amrestore -p -b 4096k -h ./2-dd-fromtape > 3-amrestore-fromdd

Which is fine.

In case it was relevent I also tried (by trial and error) to see if the
truncated version from the original amrestore fell on a tape block
boundary - it did (22 blocks including the header).   I found this by
truncating the dd'd image then running amrestore on it.

dd if=2-dd-fromtape of=4-dd-truncated-to-22-blocks bs=4194304 count=22
amrestore -p -b 4096k -h ./4-dd-truncated-to-22-blocks >
5-amrestore-fromddtruncated

The file sizes from the above can be seen below...

-rw-r--r--    1 amanda   disk     131203072 Feb 20 15:54
1-amrestore-fromtape
-rw-r--r--    1 root     root     343932928 Feb 20 16:04 2-dd-fromtape
-rw-r--r--    1 root     root     498728960 Feb 20 16:11
3-amrestore-fromdd
-rw-r--r--    1 root     root     92274688 Feb 20 16:15
4-dd-truncated-to-22-blocks
-rw-r--r--    1 root     root     131203072 Feb 20 16:15
5-amrestore-fromddtruncated

All of which seems to point to some problem with the way amrestore
interacts with the tape device.  Has anyone seem this before?

For completeness:  
Amanda 2.4.4p4
Tao Linux release 1 (Mooch Update 4) [ Rebuild of Red Hat Enterprise 3 ]
Compaq Proliant 1600R
Overland Powerloader with Quantum SDLT320 drive
Adaptec 29160 Scsi card

My tapetype definition...
define tapetype Quantum-SDLT320 {
    comment "Quantum SDLT 320 hardware compression off/ blocksize 4m"
    length 159080 mbytes
    filemark 4096 kbytes
    speed 15762 kps
    blocksize 4096 kbytes
}
[The reason for the blocksize change was to improve speed, it now
achieves speeds approaching the manufacturers quoted ones]





BMRB International 
http://www.bmrb.co.uk
+44 (0)20 8566 5000
_________________________________________________________________
This message (and any attachment) is intended only for the 
recipient and may contain confidential and/or privileged 
material.  If you have received this in error, please contact the 
sender and delete this message immediately.  Disclosure, copying 
or other action taken in respect of this email or in 
reliance on it is prohibited.  BMRB International Limited 
accepts no liability in relation to any personal emails, or 
content of any email which does not directly relate to our 
business.