Aure,

>> If you have plenty of unused "target sessions"
>> available in your jukebox and configure (or
>> reconfigure) one device to have "target
>> sessions" of 1, nsrd will tend to avoid using that
>> device.
>
> Is this really true?

This is my guessing based on my observations (in lieu of adequate
documentation...).  As always with advice/opinions from this list:
caveat emptor.

> My understanding is that a device is filled up to
> satisfiy the number of target sessions and then it
> goes on to choose the next drive. Your statement might
> be true while selecting idle drives, but I have not
> seen networker feed drives in parallel just because
> the free target sessions fall under what the others
> might have.

Nsrd does try to fill active devices before activating another device.
I have no idea what is used to determine which device should be
activated next.  This might be the place where my suggestion fails.
However, in the absence of better methods, it might come closest to the
desired result (ie, leaving 1 drive unused) albeit imperfectly.

> Assume target sessions =   4+4+4+1 and  a group with
> 14 streams starting. I am almost sure the last drive
> would anyway receive 2 streams, because target
> sessions is not a borderline, just a guideline. My
> server parallelism was set to 14, 6 more streams than
> my 2 drives are supposed to take (an initial config
> mistake), and I have seen  at least 10 sessions
> running.

You ignored the first part of my statement.  Your examples have no
unused "target sessions".

If you have target sessions at 6+6+6+1 and start 14 sessions I think
that nsrd would allocate 6 sessions to two drives, 2 to another, and
leave your "1" drive idle.  As you pointed out you might be unlucky and
get one session on your "1" drive, but my feeling is that as soon as
this finishes that drive will become idle and will not be reused (until
next time).

I'm not sure how nsrd selects devices when all suitable devices have
exceeded their target.  My guess would be that it still uses the same
algorithm and selects the one that is least over its target.  (To put
it very crudely: for each suitable device {expr $target - $current} |
sort -n | tail -1 )

Like you say, target sessions is just a guideline, not a fixed limit.
The number of sessions on a device and the target sessions settings on
those devices plays no part in determining whether a session will start
or not.

This is getting off topic, but it might help someones understanding of
how things work:

>From your POV there are two ways to get a session started:
- run "savegrp" on the server (usually started automatically by nsrd
  under your instruction), or
- run "save" (or "recover") on the client (either directly, or via
  other commands such as brbackup/backint etc).

>From nsrd's POV there is no difference between the two, they are just
requests coming from "save"/"recover" running on clients.

There is only 1 parameter that nsrd uses to determine whether to accept
or deny a new connection: server parallelism.  (Obviously the
"security" checks are performed first; I've assumed that the request
has passed these.)  Side note: nsrd reserves some slots for recovers;
even when it is maxed out doing saves you can still initiate some
recovers.

Once the connection has been accepted nsrd does device selection.  This
is based on things like device settings, pool settings, client storage
node settings, and current device use.  Included in this is the
algorithm that I've been trying to guess and discuss.

Most of the interesting job scheduling happens in savegrp.  This
implements client parallelism, group parallelism (in recent versions),
one session per disk spindle (in older versions), as well as taking
care not to be too greedy with server parallelism (in recent versions).

(BTW, this is why, in older versions, there was a recommendation
against running multiple simultaneous savegrp's.  They would each
attempt to run the max number of sessions that the server could cope
with quickly leading to headaches.  You still need to be careful not to
overload your clients...)

> I don't mean to nag, it's just my way of "learning" .

No worries, it was not taken as nagging.  Hope I'm being helpful.

George.
--
George Scott           George.Scott AT its.monash DOT edu
Systems Programmer, IT Services, Monash University

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=