On 12/01/2011 12:20 AM, mark.berg...@uphs.upenn.edu wrote: > Item 1: Administrative connections to the file daemon should not count in > the concurrency limit > Origin: Mark Bergman <mark.berg...@uphs.upenn.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.berg...@uphs.upenn.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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
