The following is a feature request that I submitted in 2007. I have edited it
in an attempt to explain the request a bit better.
Perhaps I'm overlooking something, but I couldn't find any email response
explaining why this request was not accepted initially and does not appear on
the
current feature list.
Please let me know if there's anything in the request that needs
clarification.
----
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
------- Forwarded Message
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.1
To: bacula-users AT lists.sourceforge DOT net
Bcc:
Dcc:
Subject: feature request: dynamic job priorities (bias for restores)
Mime-Version: 1.0
Content-Type: text/plain
Reply-To: mark.bergman AT uphs.upenn DOT edu
From: mark.bergman AT uphs.upenn DOT edu
X-GPG-Key:
http://pgpkeys.pca.dfn.de:11371/pks/lookup?search=mark.bergman%40.uphs.upenn.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 22 Jan 2007 19:11:24 -0500
Message-ID: <21814.1169511084@piquin>
Item 1: the numerical priority of restore jobs should be dynamically set to
make them happen sooner
Date: 22 Jan, 2007
Origin: Mark Bergman
Status: unknown
What:
Change the handling of job priorities so that more important jobs
(a lower priority) are run more promptly, by treating them as if
they were in the same priority class as currently executing jobs.
At this time, bacula will not run a job of higher importance
(lower priority) until all jobs at the level of the currently
running job complete. By masquerading the more important job to
have the same priority as the current jobs, the more important
job can run concurrently.
Within a queue of jobs of the same real (or effective--masqueraded)
priority, the jobs that have the lowest real priority would be
scheduled first.
Why:
The reason for the existance of bacula (and any backup software)
is to restore data when needed. Currently, bacula's method of
scheduling prevents a restore job of greater importance (lower
numerical priority) from running at the same time as other
jobs of less importance (higher priority), even when resources
(a tape drive) are free.
An example scenario is the following:
a backup of "slow_client1" is running at priority 10,
using tape drive 0 in the autochanger
backups of "slow_client2" through "slow_client10" are
queued, all with priority 10, all scheduled to use the
media that's in tape drive 0
I attempt to run a restore of "senior_directors_PC",
using media that's already in the autochanger, and give
the restore job priority 6. Unfortunately, the restore
will not begin until all backups are complete, though
tape drive "1" is idle.
Even if I manually set the priority of the restore job to "10"
(matching the running backups), the restore would be executed
after the backups that are already in the queue.
In the enhanced version, the restore job of files from
"senior_directors_PC"
would be assigned an effective priority of 10. Since the real priority
of the restore job is "6", that also signals that the job should be
placed
at the front of the queue of jobs in priority 10. If there was also a
restore scheduled of "corporate_presidents_PC", with priority 4, the
"corporate_presidents_PC" job would be given an effective priority of
10, but would be queued ahead of the job with an effectivie priority
of 6 and the jobs with a real priority of 10.
Notes:
Obviously, this would be subject to resource constraints (ie, you
can't work with two different volumes simultaneously in a single
device) and to the date/timestamp specified for job scheduling.
This change would be a tremendous improvement in managing
multi-drive storage devices. This method of scheduling would
make bacula more efficient, allowing higher importance (lower
numerical priority) jobs to make use of physical resources as
soon as they become available.
In some ways, this request is really a hack--the alternative
(and arguably better) method would be to change the way bacula
uses resources, so that multiple of jobs of different types &
priorities can use different physical tape drives within an
autochanger at once, but I suspect that's a much more difficult
problem.
-----
Mark Bergman mark.bergman AT uphs.upenn DOT edu
System Administrator
Section of Biomedical Image Analysis 215-662-7310
Department of Radiology, University of Pennsylvania
http://pgpkeys.pca.dfn.de:11371/pks/lookup?search=mark.bergman%40.uphs.upenn.edu
------- End of Forwarded Message
The information contained in this e-mail message is intended only for the
personal and confidential use of the recipient(s) named above. If the reader of
this message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified that you have
received this document in error and that any review, dissemination,
distribution, or copying of this message is strictly prohibited. If you have
received this communication in error, please notify us immediately by e-mail,
and delete the original message.
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
