Re: IRIX/amanda, new scsi card (!!!)
2005-04-01 15:05:53
* 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
--
<° ><
|
|
|