Not to toot my own horn too much, but I'm very happy with last night's
amanda run with the taperwait patch. I ended up with two full tapes and
no wasted space.
Note:
- if autoflush is true, the taper will write a dump on startup.
- If you get into a mode where you only have one dumper
Brian Cuttler wrote:
Largestfit() isn't some balancing act between the estimate size
and the capacity of the spool/holding area ?
What is the algorithm for starting the dumps anyway ?
ie: what DLEs does it attempt to dump first, is that based
on the taper algorithm ?
As I understand it,
On Mon, Aug 11, 2003 at 12:01:22PM -0400, Brian Cuttler wrote:
Largestfit() isn't some balancing act between the estimate size
and the capacity of the spool/holding area ?
No, it's not that smart.
What is the algorithm for starting the dumps anyway ?
Here's the pseudocode (from
Largestfit() isn't some balancing act between the estimate size
and the capacity of the spool/holding area ?
What is the algorithm for starting the dumps anyway ?
ie: what DLEs does it attempt to dump first, is that based
on the taper algorithm ?
Would it be possible for the driver not to
Brian Cuttler wrote:
Orion,
Yes, that is what I'd understood your message to be saying.
I was wondering aloud (aloud, is that the right term in email?)
because the behaviour you are seeing... it doesn't allow for the
type of taper scheduling that one might first think of when
implementing the
Jon LaBadie wrote:
On Mon, Aug 11, 2003 at 11:26:17AM -0600, Orion Poplawski wrote:
Yeah, I would love it if amanda waited until the largest dump that would
fit on the tape completed before writing anything to the tape. This
would result in a longer dump process, but I wouldn't mind because
Would it be possible for the driver not to queue up a tape job in
startaflush()? I'm using LARGESTFIT, but for the most part dumps end up
getting flushed to tape as they come in because there is often only one
dump in the queue when startaflush() is called. I would like it if (at
least with
