In the message dated: Thu, 01 Dec 2011 09:48:59 +0100,
The pithy ruminations from Bruno Friedmann on
<Re: [Bacula-users] feature request: exempt administrative connections from con
currency limits> were:
=> On 12/01/2011 12:20 AM, mark.bergman AT uphs.upenn DOT edu wrote:
=> > Item 1: Administrative connections to the file daemon should not count
in the concurrency li
=> mit
=> > Origin: Mark Bergman <mark.bergman AT uphs.upenn DOT edu>
=> > Date: Wed Nov 30 18:03:20 EST 2011
=> > Status:
=> >
=> > What:
=> > Administrative connections to the file daemon should not count
=> > in the concurrency limit.
=> >
=> > These connections to the file daemon (ie., "stat dir" or "cancel
=> > dir") are treated as if they were backup connections. This means
=> > that these commands will be refused if the maximum number of
=> > concurrent jobs are running.
=> >
[SNIP!]
=>
=> Mark I saw a limit to your request :
=> What about restore ? How would you manage/count them
Hmmm.... I'd suggest not changing the way that restores are managed.
=>
=> Example : You have a very long running backup
=> Then a client need very quickly a restore (from another job)
=> If you have limited connexions you will be not able to execute the restore.
=>
There's always a limited number of connections, whether that limit is
1 or the default of 20. If you have "N" jobs running (where "N" is the
limit) then the next job will not run. For regular jobs (ie., backup or
restore) this isn't a big problem, as the job will be queued (depending
on things like "Max Start Delay"). Administrative commands ("stat dir",
"cancel jobid") just hang if they can't connect to the file daemon...and
it wouldn't make sense to queue those commands until running jobs
finish. Administrative commands should be executed as soon as possible.
=> But with your proposal, how restore should be counted ?
My proposal doesn't change the way restores are handled at all.
It might be worth submitting another feature request, such as allowing
"N" concurrent backup jobs plus "R" concurrent restore jobs (and if
"R = 0", then the behavior is unchanged from the current version of
bacula, giving backward compatibility).
=> Or will you tell to the customers that restore will only happen in several
hours after the backu
=> p ?
Actually, that's what I often tell users. We've got 2 physical tape
drives. If they are both in use, then there is no way for a restore job
to pre-empt the running backups.
Unless this has changed in recent versions, Bacula concurrently runs
jobs of only one priority level at a time. This means that a critical
'restore' job (with priority '1') will wait until the unimportant backup
(priority '10') that is currently running finishes, even if there are many
unused tape drives. If you set the restore job to the same priority as
the running backup, it could run simultaneously...but any other backups
could also run, possibly filling all tape drives.
=>
=> Sorry, I'm just asking questions
No problem...they're good questions.
Mark
=>
=> --
=>
=> Bruno Friedmann
=> Ioda-Net SÃ rl www.ioda-net.ch
=>
=> openSUSE Member & Ambassador
=> GPG KEY : D5C9B751C4653227
=> irc: tigerfoot
=>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d _______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
