On Thu, 6 Dec 2001 at 3:09pm, Dan Garthwaite wrote
> In the section "GENERATING SCHEDULE:" in amdump's log the input to
> read_schedule() in driver.c? If so, then I have the erroneous lines (
> depending if 'line' the counter var is 0 or 1 based )
>
> GENERATING SCHEDULE:
> amanda.mtg.saic.com //gagnona/F$ 11661 0 1970:1:1:0:0:0 0 0 1818845508
> amanda.mtg.saic.com //isis_temp/F$ 11661 0 1970:1:1:0:0:0 0 0 1818845508
> Here is the field with the huge number. I guess these two hosts are timing
> out.
> I'm off to go see what the client's cifs/tcp settings are.
>
I think the issue is in planner.c. Let's look at //isis_temp/F$. In
amdump.3, under "GETTING ESTIMATES", we see:
got result for host amanda.mtg.saic.com disk //isis_temp/F$: 0 -> 1K, -1
-> -1K, -1 -> -1K
which matches what's in sendsize*debug -- it's an estimate, but a small
one (1K for a level 0). But, under "ANALYZING ESTIMATES":
pondering amanda.mtg.saic.com://isis_temp/F$... next_level0 -11660
last_level -1 (due for level 0) (no estimate for level 0, picking an incr
level)
planner doesn'tt think it got an estimate. Here's the bit of code that
generates that:
if(ep->dump_size <= 0) {
fprintf(stderr,
"(no estimate for level 0, picking an incr level)\n");
ep->dump_level = pick_inclevel(dp);
ep->dump_size = est_tape_size(dp, ep->dump_level);
}
But dump_size should be 1, not 0, so that's getting lost for this disk
somewhere. There's also no degraded mode info for this disk, but that
junk string is still getting output. *sigh*
Grasping at straws -- could you try upgrading to the recently announced
2.4.3b1? I *do* recall some fixes going into CVS for large numbers of
clients, and I don't feel like we're getting any closer here. And, before
you ask, people have run on 'b' releases in production for quite a while,
so don't let that scare you *too* much...
--
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University
