Gene,
Thanks for the tape label sequence, will re-label the next couple
of tapes and see if I don't get different results from the next
amdump run. (commands reproduced below).
If this solves the problem perhaps it should be incorporated into amlabel.
Alexander,
Hadn't realized that the 1st chunk on disk was broken into the
amanda header followed by the collected chuncks. Makes sense if
you think about it.
New information------
The amdump run I started yesterday completed in record time. 51 hours
of dump time and only 33 hours of elapse time.
I tried to amrestore several dumps from the tape to disk, oddly
the restores of the DUMP DLE both failed, the restore of the TAR
DLE sort of worked, I can... I'm an idiot.
I was able to take the DLE restored from tape and # tar -tf the
tar ball but was unable to restore it with # tar -xvf. On second
look I've realized that I can, and MUST, use gnutar and was then
able to restore the files.
Suddenly its looking like TAR DLEs are a non-issue. (well, move below)
Things are still anomalous with the DUMP DLEs though.
samar 22# mt -f /dev/sdlt2 rewind
samar 23# /usr/local/sbin/amrestore /dev/sdlt2 samar /usr1
amrestore: 0: skipping start of tape: date 20041229 label SAMAR24
amrestore: 1: skipping samar._usr5_lalor.20041229.0
amrestore: 2: skipping samar._usr5_tapu.20041229.1
amrestore: 3: skipping samar._.20041229.1
amrestore: 4: skipping samar._usr5_amanda.20041229.1
amrestore: 5: skipping samar._usr5_bimal.20041229.1
amrestore: 6: skipping samar._usr5_allengr.20041229.2
amrestore: 7: skipping samar._usr5_skaur.20041229.1
amrestore: 8: skipping samar._usr5_leith.20041229.1
amrestore: 9: skipping samar._usr5_hxgao.20041229.1
amrestore: 10: skipping samar._usr5_ninggao.20041229.1
amrestore: 11: restoring samar._usr1.20041229.0
amrestore: read error: I/O error
gzip: stdin: unexpected end of file
This created a zero length file for samar._usr1.20041229.0
Same result for the DUMP DLE for the root partition.
Same result when I tried to pipe directly to xfsrestore.
samar 31# /usr/local/sbin/amrestore -p /dev/sdlt2 samar /usr5/bimal |
/usr/local/sbin/gnutar -tf -
amrestore: 0: skipping start of tape: date 20041229 label SAMAR24
amrestore: 1: skipping samar._usr5_lalor.20041229.0
amrestore: 2: skipping samar._usr5_tapu.20041229.1
amrestore: 3: skipping samar._.20041229.1
amrestore: 4: skipping samar._usr5_amanda.20041229.1
amrestore: 5: restoring samar._usr5_bimal.20041229.1
./
./cvs_test/
./cvs_test/spider/
./cvs_test/spider/CVS/
./cvs_test/spider/man/
amrestore./cvs_test/spider/man/CVS/
: read error: I/O error./cvs_test/spider/src/
./cvs_test/spider/src/CVS/
./hpc/
./hpc/eve/
./hpc/eve/hpc/
./hpc/eve/hpc/dynamic/
./hpc/eve/hpc/dynamic/new/
--lines removed for brevity (like that'll help now).
./pick_part/classify/Power_Spectra/power/
./pick_part/classify/Reconstruction/
./pick_part/classify/Refinement/
./pick_part/final/
./pick_part/final/0deg_proj_asym_mask/
./pick_part/final/0deg_proj_asym_mask/interpolated/
./pick_part/final/0deg_proj_asym_mask/interpolated/new/
./pick_part/final/0deg_proj_sym_mask/
gzip: stdin: unexpected end of file
./pick_part/final/0deg_proj_sym_mask/interpolated/
/usr/local/sbin/gnutar: Unexpected EOF in archive
/usr/local/sbin/gnutar: Error is not recoverable: exiting now
Actually at this point I'm not sure... that file name is familiar
and I don't know we didn't error while writing the file to tape
in the first place.
No errors reported in the amdump report, read of disk was completely
clean, unlike the previous output that I posted.
We are close, but the results of this run seem to weaken the argument
for disk block/record issues.
> >I can switch to a fixed length device by removing the trailing 'v'
> >in the device name. It hasn't been an issue on other systems though
> >I admit that this SDLT on IRIX is unique at my site.
>
> Those are commands in the 'mt' arsenal Brian. And there have been
> known to be platform diffs, so consult the manpages for your
> version, and, make sure you have the latest version.
>
> Mine possibly isn't quite fresh and 100% green, but it works and returns:
>
> mt-st v. 0.7
>
> for an mt --version command
>
> >> Back when I was running real tapes, I found that a 32kilobyte
> >> record was measureable faster than the default of 512 bytes. But,
> >> if everything isn't set to the same record length, the whole thing
> >> blew up for me. Is there any way you can make it run fixed length
> >> records on that lashup?
> >
> >Block size on tape. Where is that set, is this a function of the
> >underlying DD command within Amanda or is this elsewhere ?
>
> You can spec the block size used by dd with the bs option, but the
> tape itself must know about it first by useing the appropriate mt
> command. Again, there are platform diffs, but here is the -h
> output from my copy:
> [root@coyote root]# mt -h
> usage: mt [-v] [--version] [-h] [ -f device ] command [ count ]
> commands: weof, wset, eof, fsf, fsfm, bsf, bsfm, fsr, bsr, fss, bss, rewind,
> offline, rewoffl, eject, retension, eod, seod, seek, tell, status,
> erase, setblk, lock, unlock, load, compression, setdensity,
> drvbuffer, stwrthreshold, stoptions, stsetoptions, stclearoptions,
> defblksize, defdensity, defdrvbuffer, defcompression, stsetcln,
> sttimeout, stlongtimeout, densities, setpartition, mkpartition,
> partseek, asf.
> [root@coyote root]#
>
>
> You would be useing the setblk and defblksize, or the equ in your copy.
> From the cli:
> #>mt -f device setblk 32768
> #>mt -f device defblksize 32768
>
> Then you can use a
> #>dd if=/path/to/device of=scratch count=1
> This will read the tapes label out to a tmp file you'll need later
> #>mt -f device rewind
> Then issue the above pair of commands
> #>dd if=scratch of=path/to/device bs=32768 xx=xxxxxxx
> Where the xx=xxxxxx stuff is replaced by whatever command
> dd uses to make it pad a short input file on out to the blocksize
> I'd have typed it here but I've forgotten it, check the manpage
> for that detail.
>
> Now feed the drive enough data to make it flush the buffers making
> it refresh the expected bloccksize in the hidden header, so figure
> out how many of those 32768 chunks will cause the drives
> advertized buffer to overflow, and use
> #>dd of=/path/to/device if=dev/zero bs=32768 count #howmany
>
> Once you've done that to each tape, and installed the block size
> setter stuff in whatever the AIX uses for the linux /etc/rc/rc.local
> file so it gets reset everytime its booted it should run pretty
> smoothly
>
> >> mt has the commands required to set the record size used.
> >
> >I'd hate to have to that another 25 times (and whenever I replaced
> >volumes). How long did it take to sus out the sequence ?
>
> I expect I fiddled with it the better part of a day, spread out
> over several days, basicly playing the 10,000 monkeys writing
> ShakeSpears stuff all over again. I also learned something else.
> Don't every try to erase one of these tapes with a bulk eraser
> like we us on video tapes at the tv station. First, its not
> strong enough to do a good job, and two it mucks with the
> tape identification to the drive, rendering the tape into
> a rather lightweight paperweight.
>
>
---
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
|
