Amanda-Users

Re: add new clients, lost order scheduleing, tape isn't streaming

2003-05-30 10:43:44
Subject: Re: add new clients, lost order scheduleing, tape isn't streaming
From: Gene Heskett <gene.heskett AT verizon DOT net>
To: amanda-users AT amanda DOT org
Date: Fri, 30 May 2003 10:39:23 -0400
Resent on the list Jon, I'm bouncing again

On Friday 30 May 2003 04:07, Jon LaBadie wrote:
>On Fri, May 30, 2003 at 03:15:54AM -0400, Gene Heskett wrote:
>> Hi everybody;
>>
>>
>> Now the client is a bit slow, a 500mhz K6-III, so I expected the
>> level 0's this would cause would take a while.  This also brought
>> my disklist entries up to 44.  The string that controls the
>> dumporder in amanda.conf:
>> dumporder "SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS"
>> *should* cause the largest first, then descending order, and there
>> are enough S's to cover all DLE's such that once the first dump is
>> ready, the drive streams till its done.
>
>I think you have the wrong idea of dumporder.  My understanding is
> this: One parameter in amanda.conf is "dumpers", default I think to
> 4.  This is how many DLE's can be simultaneously dumping.  Your
> dumporder needs be no longer than this number.
>
>Because they are simultaneous, you might start DLE's hypothetically
> of 20GB, 18GB, and 15GB.  The the 4th dumper doing the 4th largest
> might get one of 0.5GB.  This could finish rapidly and keep getting
> assigned the next largest DLE which should be smaller than 0.5GB
> and also finish fast.  So lots of DLE's could finish before your
> large one even if the large ones started first.
>
>However, I have no idea why your large one started later rather than
>according to the scheme above.

Oh it started first alright according to amstatus, its just that it 
took it about 2:20 to complete that one dump on the old workhorse.

According to amplot, it fired up the tape and wrote for about 20 
minutes, then rested the tape for another 50 minutes before it 
started writing that first dump.  And it did the first 33 DLE's on 
the server in that first 20 minute write, not all of which were the 
largest.  The only way it could have done that would be for the last 
2 dumpers to always draw an uncompressed DLE that was only an 
incremental.  And the next largest dump was on the server was set for  
'compress client best'.  One thing I think I'll do is write another 
dump spec, the same as comp-root-tar but it says 'compress server 
best' for those DLE's on the server proper.  Or is that just robbing 
peter to pay george?  There should be less data to shuffle thru the 
le0 connection if its 'client' I'd think.  I think I need my first 
tea of the day, this isn't jelling too well...

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.26% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.



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