On Friday 30 May 2003 05:27, Paul Bijnens wrote: >Gene Heskett wrote: >> 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. > >They all start together, but which dump will be ready first you >think? It's probably one of the smaller dumps! >I guess not all 44 dumpers will be active, because you probably have >other constraints (maxdumpers per host, per disk, bandwith etc,). > Miss-conception I think, 44 DLE's, but its the default 4 dumpers in the amanda.conf (on the server).
>Taper starts taping as soon it receives the first file to tape, and >that's probably a smaller one. So basicly it had the 1 dumper running on the client, and 3 running on itself, and they went thru the biggest 33 files on the server while the 1st one on the client completed. Mmm, the counts are correct, but they didn't 100% start with the biggest ones on the server since it had taped 650 megabytes of server stuff by then, but the server still had at least 2 to do yet that were more than the 650 megs the first 33 had totalled, each. Thats what got my attention. >Using less dumpers should work better. Less than 4? ------from amanda.conf----- inparallel 4 # maximum dumpers that will run in parallel (max 63) # this maximum can be increased at compile-time, # modifying MAX_DUMPERS in server-src/driverio.h [...] dumporder "SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS" # specify the priority order of each dumper # s -> smallest size # S -> biggest size # t -> smallest time # T -> biggest time # b -> smallest bandwitdh # B -> biggest bandwitdh # try "BTBTBTBTBTBT" if you are not holding # disk constrained # BUT, if you want streaming, start with the big ones and work down ----------- Maybe I should change the first 5 or 6 to T's? OTOH, if it starts taping when the first one is done, Theres not a heck of a lot I can do, that machine is overclocked as far as it will without effecting the uptimes now. If it held them in the holding disk to achieve the specified order, it would have waited over 2:20 for the first, actually the biggest, after "compress client best" compression. According to amplot, the tape was running from about :45 to about 1:15, then was resting for about another 50 minutes before fireing up and finishing the job at the 3:55 mark, certainly not as tape wastefull as running without a holding disk would be. And either way the total runtime would be pretty much the same for the same set of conditions. Thanks Paul. -- Cheers, Gene AMD [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 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.