On Thu, Aug 03, 2006 at 08:25:43AM -0700, Joe Donner (sent by Nabble.com) wrote:
> 
> Well,  I may have "lied" a bit when saying that nothing had changed...
> 
> What did change was that I moved the server from temporarily sitting on the
> floor to where it will now stay full-time.  So it was a shutdown, unplug the
> external tape drive and other devices, and then plug them all back in. 
> Also, one of the little screws which connects the SCSI cable to the back of
> the server has long ago broken off and gone missing.  So it's only attached
> by one screw.
> 
> Well, do you agree with me that it is still backing up the same amount of
> data and all the DLEs?  It certainly looks that way from the mail reports. 
> I'm a bit worried because it's looking "too good to be true".
> 
> I also don't see how it can dump 130-odd gigabytes of data within a bit more
> than 3 hours??
> 
> Thanks for your help on this.
> 
> 
> Jon LaBadie wrote:
> > 
> > On Thu, Aug 03, 2006 at 02:46:06AM -0700, Joe Donner (sent by Nabble.com)
> > wrote:
> >> 
> >> That was definitely not the case.  The holding disk has been empty all
> >> this
> >> time, except on 31 July.  And after I ran amflush it was empty again.
> >> 
> >> What I don't understand is the increase in dump time and tape time?  They
> >> both more than doubled in speed!  How is that possible?
> >> 
> >> 
> >> Olivier Nicole wrote:
> >> > 
> >> >> I honestly haven't changed anything.  The only thing that happened was
> >> >> that
> >> >> I had to run amflush on July 31, because for some reason the
> >> >> amanda-related
> >> >> services on the backup server seemed to have hung (but that's an
> >> entirely
> >> >> different issue).
> >> > 
> >> > That si just a wilkd guess, but how about the amflush has freed space
> >> > on your holding disk that had been wasted for ages?
> >> > 
> > 
> > Holding disk issues were going to be my guess also.
> > 
> > When the run time (wall clock) and tape time (taper
> > is active) match as the first two:
> > 
> > Run Time (hrs:min)         9:43
> > Dump Time (hrs:min)        6:21
> > Tape Time (hrs:min)        9:23
> > 
> > Run Time (hrs:min)         9:43
> > Dump Time (hrs:min)        6:17
> > Tape Time (hrs:min)        9:23
> > 
> > it "generally" means your dumps are going straight to tape.
> > Contrast that with the last two where time for taping the
> > same amount of data is greatly lower than total run time.
> > 
> > Run Time (hrs:min)         4:03
> > Dump Time (hrs:min)        3:12
> > Tape Time (hrs:min)        1:17
> > 
> > Run Time (hrs:min)         4:27
> > Dump Time (hrs:min)        3:37
> > Tape Time (hrs:min)        1:16
> > 
> > However, if the dumps were going straight to tape then I
> > would expect the dump time (cumulative time for dumping of
> > each DLE - thus can be > run time if DLEs dump in parallel)
> > to match tape time.
> > 
> > So it would appear the dumps were going to the holding disk
> > but were severely constrained by slow tapeing.  I wonder
> > about the halving of dump time also.  There may still have
> > been a problem with the disk system.
> > 
> > Did anyone change any scsi cables or terminators.
> > Or maybe the just "jiggled" things back there doing other work?
> > 
> > 

Are you using that SDLT drive for which you reported a tapetype
back in early June?  If so, you have had a problem since then.

In June your tapetype showed 2200 k/s.
Similarly, your recent slow dumps had a
tapeing speed of about 2500 and 1800 k/s.

Your more recent fast dumps were taped at about 13000 k/s.
The sdlt is rated at 16000 k/s.

I'd say you had tape system problems
fixed by physical movement or reboot.

-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)