On Fri, Nov 03, 2000 at 05:55:20PM -0500, John R. Jackson wrote:
> I looked at your amdump.1 log and the code for quite a while this
> afternoon and am not sure what happened. It looks like the driver
> algorithm for choosing the next dump to process may have trouble with
> some restricting situations in conjunction with you not using a tape.
> For instance, it looks like the code might decide to send a dump direct
> to tape when there doesn't appear to be enough bandwidth. That does
> not appear to be what's happening to you, but it would cause what you
> are seeing.
I think that's what's happening, a dump with est_kps larger than the
bandwidth will never be scheduled to dump on holding disk.
This patch will allow a dump to be scheduled if no other dumpers use
the interface.
Untested patch.
Jean-Louis
--
Jean-Louis Martineau email: [EMAIL PROTECTED]
Departement IRO, Universite de Montreal
C.P. 6128, Succ. CENTRE-VILLE Tel: (514) 343-6111 ext. 3529
Montreal, Canada, H3C 3J7 Fax: (514) 343-5834
--- driver.c.orig Fri Nov 3 20:40:42 2000
+++ driver.c Fri Nov 3 20:45:08 2000
@@ -559,7 +559,8 @@
sleep_time.tv_sec);
any_delayed_disk = 1;
}
- else if(sched(diskp)->est_kps > free_kps(diskp->host->netif))
+ else if(sched(diskp)->est_kps > free_kps(diskp->host->netif) &&
+ diskp->host->netif->curusage > 0)
cur_idle = max(cur_idle, IDLE_NO_BANDWIDTH);
else if((holdp = find_diskspace(sched(diskp)->est_size,&cur_idle,NULL)) ==
NULL)
cur_idle = max(cur_idle, IDLE_NO_DISKSPACE);
