Amanda-Users

Re: IRIX/amanda, new scsi card (!!!)

2005-04-01 15:05:53
Subject: Re: IRIX/amanda, new scsi card (!!!)
From: Jean-Francois Malouin <Jean-Francois.Malouin AT bic.mni.mcgill DOT ca>
To: Brian Cuttler <brian AT wadsworth DOT org>
Date: Fri, 1 Apr 2005 14:52:34 -0500
* Brian Cuttler <brian AT wadsworth DOT org> [20050401 14:42]:
> 
> IRIX     6.5.25, upgraded today from 6.5.19
> Amanda   2.4.4p1-20030716
> 
> Hello amanda users,
> 
> This will sound familiar to some of you, at least its good news,
> of a sort.
> 
> This is likely an SGI question, but I thought I'd see if it
> sounded familiar to anyone and wanted to also thank you again
> for your previous help on this issue (several months ago, I've
> been waiting for a hardwar delivery).
> 
> Remember that SGI Origin 300, SCSI daisy-chain to raid array, to
> sdlt/jukebox to sdlt/shoebox. It violated the length of the scsi
> chain, it shouldn't have but it turned out the robot was narrow
> and that had a big effect on the bus.
> 
> Well, the new pci-scsi card came in and we installed it. IRIX will
> not see the card under 6.5.19 but did after an upgrade to 6.5.25.
> 
> Modified amanda.conf to see the sdlt/jukebox on the new bus, all 
> other devices where left on the original bus. Both buses are now
> within legal parameters.
> 
> I reset the blocksize on the tape drive, will need to do this
> after each reboot apparently. # mt -f /dev/rmt/tps7d4nrns setblksz 32768
> 
> Though perhaps we should choose a different value.
> 
> samar 83# ls -l /dev/sdlt2
> lrwxr-xr-x    1 root     sys           19 Apr  1 13:25 /dev/sdlt2 -> 
> /dev/rmt/tps7d4nrns
> 
> samar 81# mt -f /dev/sdlt2 status
>         Controller: SCSI
>         Device: QUANTUM: SDLT320         3838±8
>         Status: 0x22260
>         Drive type: unknown
>         Media : READY, writable, not at BOT, block 1
> 
> samar 82# mt -f /dev/sdlt2 blksiz
> 
>  Recommended tape I/O size: 204800 bytes (400 512-byte blocks)
>  Minimum block size: 4 byte(s)
>  Maximum block size: 16777212 bytes
>  Current block size: 32768 byte(s)
> 
> Anyway - it seems to work and I am able to use amrestore to pull
> a DLE back from tape to disk. For the first time/finally.
> 
> But I'm unable to read the restored file, either from the copy
> of the file on disk or directly using the amrestore -p and a 
> pipe to xfsrestore.
> 
> samar 84# xfsrestore -if samar._usr5_tapu.20050401.1 /usr5/dumps/restore
> xfsrestore: using file dump (drive_simple) strategy
> xfsrestore: version 3.0 - type ^C for status and control
> xfsrestore: searching media for dump
> xfsrestore: ERROR: media file header checksum error
>  :
>  :
> xfsrestore: ERROR: media file header checksum error
> xfsrestore: ERROR: media file header magic number mismatch
> xfsrestore: restore complete: 1 seconds elapsed
> xfsrestore: Restore Summary:
> xfsrestore:   stream 0 (pid 6245) /tmp/restore/samar._usr5_tapu.20050401.1 OK 
> (success)
> xfsrestore: Restore Status: SUCCESS
> 
> Any idea what is wrong with the dump file ? Suspect its not an amanda
> issue but thought I'd ask.

Did you try a variable block size tape device, ie tps7d4nrnsv

jf

> 
>                                               thank you,
> 
>                                               Brian
> ---
>    Brian R Cuttler                 brian.cuttler AT wadsworth DOT org
>    Computer Systems Support        (v) 518 486-1697
>    Wadsworth Center                (f) 518 473-6384
>    NYS Department of Health        Help Desk 518 473-0773

-- 
<° ><

<Prev in Thread] Current Thread [Next in Thread>