On Tue, Dec 03, 2002 at 10:57:19AM -0600, Matthew Boeckman wrote: > After resolving my earlier problems, I've uncovered a new one. Amanda is > timeing out, apparently while waiting for estimates on one of my hosts. > I think I can fix this by bumping the timeout value,
Looks like this would be the thing to do. [clip] > nocomp tar on 4 directories (bkup1, 2, 3, 4) on the 100+GB filesystem [clip] > the behavior: If I remove all but 1 of the bkup partitions from > disklist, amanda runs fine, whenever I try to run with bkup1-4 in the > disklist, I get: > ultra /webhome/bkup4 lev 0 FAILED [Request to ultra timed out.] > for all partitions. [clip] > perplexed, as it kind of appears from these two that amanda was trying > to do both lvl 0's and lvl 1's of some of the partitions! Rather, she's estimating what would happen if she did a level 0 or level 1, so she can make a rational decision. Total allowed estimate time for a client is (etimeout * # of DLEs). If all estimates for that client are not finished by then, the client is skipped completely. It is common for estimates to take a loooong time on DLEs with a large number of small files; crank up etimeout by 2X/4X and see what happens. You may hit dtimeout next, you know what to do. :-) Make sure your GNU tar is appropriately recent (1.13.25), I've observed older versions running pathologically long --listed-incremental times on Solaris. > sendsize: debug 1 pid 1796 ruid 602 euid 602 start time Tue Dec 3 01:00:07 2002 [clip] > sendsize: pid 1796 finish time Tue Dec 3 02:19:31 2002 So the estimate does finish, in just over an hour. Default etimeout is 5 minutes, and you're doing 6 DLEs on ultra, so amdump is only waiting 30 minutes, and you lose. The one hour+ estimate time is survivable, so make sure GNU tar is new, bump etimeout to 800 or 1000 or 1200 seconds, and go for it. -- Jay Lessert [EMAIL PROTECTED] Accelerant Networks Inc. (voice)1.503.439.3461 Beaverton OR, USA (fax)1.503.466.9472
