On Friday 31 December 2004 10:49, Brian Cuttler wrote:
>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.

But, otoh, its strengthening the argument to use gnutar only.

And I'd make the suggestion that somewhere in this setup, there is 
insufficient iron to do the job.  I don't know anything about an 
SDLT, but if its taking 33 hours of real time, that drive has got to 
be doing a lot of "shoe shining" where it collects data till the 
buffer is about full, starts up and dumps that to the tape, then 
stops and does a short rewind so that it doesn't waste a lot of blank 
tape in between data writes.  The server should have enough bandwidth 
at the drive cable to keep the pipe full so that once it starts, it 
streams data at the rate the drive can take it, at least for the 
duration of that dle's dump from the holding disk.  A 150 mhz cyrix 
hasn't the power, and here, a 400mhz k6-II wasn't able to keep a puny 
little DDS2 drive 100% busy either.

Here, using virtual tapes on a dedicated hard drive, a 16GB before 
compression backup run that fits in a bit over 9GB after gzip gets 
through with it, starts a few minutes after midnight, and is often 
done by 2:15 am.  But, during the dump time from the holding disk to 
the virtual tape, the machine is virtually frozen, only the xwindow 
clock seems to keep on counting normally.  Using the 4GB tapes, it 
was often close to 4 am when it spit out the backup report, for less 
than half the data per run.

There has been a suggested rule of thumb for tape drives and 
capacities put forth that says that if it takes the drive, in 
streaming mode, more than 3 hours to complete that backup by writing 
a nearly full tape, its too small and slow if its streaming 100% of 
the time.  So if its takeing 33 hours to fill one tape, that tells me 
the server is struggling, and the drive is shoe-shining the tape 
because its not getting its data fast enough.  That indicates a 
server upgrade is needed rather badly.  Its also hell on the tape, 
reducing its available passcounts to half or less and increases the 
wear and tear on the heads considerably.  Is that upgrade possible 
given the budget & whomever is controlling that for you?

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.31% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.