On Fri, Jan 07, 2005 at 03:40:12PM -0500, Brian Cuttler wrote:
> samar 5# /usr/local/sbin/amrestore -r /dev/sdlt2
> amrestore:   0: skipping start of tape: date 20050107 label SAMAR05
> amrestore:   1: restoring samar._usr5_amanda.20050107.1
> amrestore: read error: I/O error
> [likewise with "dd bs=32k"]

Ooo, I don't like the look of "I/O error" at all.  That suggests
a hardware or media problem, as opposed to anything that software
has any control over.

If you haven't done so (can't recall; maybe you've already
described this), look in the system logs for errors from that
device.  If there aren't any, it couldn't hurt to take a look at
the driver's man page (and pages for the SCSI subsystem in
general -- it is a SCSI drive, isn't it?) to see if more verbose
error reporting can be enabled.

If you come up with anything, please post it.

> samar 12# mt -f /dev/sdlt2 rewind
> samar 13# mt -f /dev/sdlt2 fsf 1
> samar 14# cat -evt /dev/sdlt2 | more
> Input error: Invalid argument (/dev/sdlt2)

This one's to be expected.  "cat" uses a smaller block size --
and unlike "dd", you can't change it.

> samar 15# mt -f /dev/sdlt2 rewind
> samar 16# mt -f /dev/sdlt2 fsf 1
> samar 17# dd if=/dev/sdlt2 bs=32768| cat -evt | more
> AMANDA: FILE 20050107 samar /usr5/amanda lev 1 comp .gz program 
> /usr/local/sbin/
> gnutar$
> To restore, position tape at start of file and run:$
> ^Idd if=<tape> bs=32k skip=1 | /usr/sbin/gzip -dc | usr/local/sbin/gnutar 
> -f... 
> -$
> ^L$
> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
> 
> 
>  ** many null characters removed.

Hmmm, I'd have expected to see "Read error: I/O error" again
here, seeing as you get it on every other 32-KB read.  Odd that
the message is missing while the main output is still as though
the error had occurred.

> samar 18# mt -f /dev/sdlt2 rewind
> samar 19# mt -f /dev/sdlt2 fsf 1
> samar 23# dd if=/dev/sdlt2 bs=32768 skip=1 | /usr/sbin/gzip -dc | 
> /usr/local/sbin/gnutar -tf - | more
> Read error: I/O error
> 0+0 records in
> 0+0 records out
> 
> gzip: stdin: unexpected end of file

Yeah, more of same... If dd can't get the bits off the tape,
there's not much point trying to do different things with its
nonexistent output :-(

> I had followed Gene's instructions

I've never had to use these, so my comments here are pretty
tentative.

> [Commands to show that the tape drive is set for
> variable-length blocks, stash the label in ./scratch, and
> verify that the label was stashed ok.]

I don't see the command to set the drive to 32768-byte blocks,
but it's presumably there becuse:

> samar 32# mt -f /dev/sdlt2 blksize
> 
>  Recommended tape I/O size: 131072 bytes (256 512-byte blocks)
>  Minimum block size: 4 byte(s)
>  Maximum block size: 16777212 bytes
>  Current block size: 32768 byte(s)
> 
> samar 33# mt -f /dev/sdlt2 rewind
> 
> samar 34# mt -f /dev/sdlt2 blksize
> 
>  Recommended tape I/O size: 131072 bytes (256 512-byte blocks)
>  Minimum block size: 4 byte(s)
>  Maximum block size: 16777212 bytes
>  Current block size: 32768 byte(s)
> 
> samar 35# dd bs=32768 if=scratch of=/dev/sdlt2
> 1+0 records in
> 1+0 records out

If I recall from Gene's description of the problem, it's only
when you go to *read* a tape that your setting gets magically
zapped.  So it couldn't hurt to do a final:
        mt rewind
        dd bs=32k </dev/sdlt2 >./scratch2
        mt -f /dev/sdlt2 blksize
to verify that that hasn't happened.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        erics AT telepres DOT com
|  |  /
The animal that coils in a circle is the serpent; that's why so
many cults and myths of the serpent exist, because it's hard to
represent the return of the sun by the coiling of a hippopotamus.
        - Umberto Eco, "Foucault's Pendulum"