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 limit
>   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.
> 
>   Why:    
>        The file daemon may be configued with a low concurrency
>        value to deliberately prevent multiple backups from running
>        simultaneously. Use of a low value is especially important
>        in an enterprise setting, where a bacula client may be a file
>        server with large disk volumes that should not be backed up
>        concurrently to avoid I/O contention on the file server.
> 
>        If "Maximum Concurrent Jobs" is set to "1", then all other
>        connections to the file daemon will be refused, including
>        administrative commands.
> 
>        Setting the concurrency value to another low value (ie., 2,
>        3, etc.) both defeats the purpose of limiting I/O contention
>        and actually makes the problem worse. As soon as the maximum
>        number of backups (the concurrency limit) are running, then
>        it becomes impossible to cancel any of the jobs--exactly at a
>        time when I/O or network contention become a problem and some
>        of the jobs should be canceled.
> 
> 
>   Notes: A similar issue may exist for the other concurrency
>        limits applied to the director and storage daemon.
> 
> ----
> Mark Bergman                              voice: 215-662-7310
> mark.bergman AT uphs.upenn DOT edu                 fax: 215-614-0266
> System Administrator     Section of Biomedical Image Analysis
> Department of Radiology            University of Pennsylvania
>       PGP Key: https://www.rad.upenn.edu/sbia/bergman 
> 

Mark I saw a limit to your request :
What about restore ? How would you manage/count them

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.

But with your proposal, how restore should be counted ?
Or will you tell to the customers that restore will only happen in several 
hours after the backup ?

Sorry, I'm just asking questions

-- 

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