At 2009-10-30 15:24 -0400, David McMullin <David.McMullin AT CBC-Companies DOT
> So even though I have a higher priority queued duplication job
> waiting for a tape, a lower priority backup will grab that same
> tape to write to it.
It sounds like your NBRB queue is backed up.
> Anyone else have these issues?
Yes (although I've seen it the other way 'round).
> I found documentation for /usr/openv/var/global/nbrb.conf at
> page 162 and following:
> RESPECT_REQUEST_PRIORITY = 0
> SECONDS_FOR_EVAL_LOOP_RELEASE = 180
> DO_INTERMITTENT_UNLOADS = 0
> (These are defaults)
> Is this what I need to modify? and what to set the values for?
Actually, I think the performance tuning guide is out of date on the
defaults: as of 6.5.4, DO_INTERMITTENT_UNLOADS defaults to 1 (see
the SLP best practices doc,
which is probably where you want it: that means that when NBRB
breaks out of its evaluation loop, it will unload drives that have
been sitting idle (which will keep another backup job from picking
up on the same tape a finished one used and still keeping your
duplication from getting the drive).
The main problem you're seeing is that the NBRB queue is rather
long and, although the daemon breaks out every 180 seconds to refresh
the queue (which is sorted by priority), when it starts processing
again it picks up where it left off and runs to the bottom (meaning,
satisfies the requests) of the queue of requests before returning
to the top and seeing the higher-priority, newly-queued jobs.
If you change RESPECT_REQUEST_PRIORITY to 1, NBRB, after it breaks
out every 180 seconds, will return to the top of the newly-refreshed
queue, which will meaning that your higher-priority jobs will get
Give it a try with DO_INTERMITTENT_UNLOADS and
RESPECT_REQUEST_PRIORITY both set to 1.
gr AT eclipsed DOT net
Description: PGP signature
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu