On 14-10-24 05:28 AM,
Andrea Carpani wrote:
On 24/10/2014
12:47, Kern Sibbald wrote:
No, the SD
and the FD cannot be reloaded. On the FD in principle it
would be easy, but on the SD, it would be complicated if
drives
changed. What would you do with Jobs that are using a
drive that
would be removed from the reload?
I'm not that deep into backup software, so maybe I'm saying
something
stupid, but a config reload could do the same thing that
other software
do, that is:
- continue servicing current requests with the previous
conf and
- use the new conf for new requests.
Something like a graceful restart apache does.
Does this make sense?
.a.c.
Sense to humans yes, sense to program code not so much.
The nature of the SD is that its configuration should almost
never change - all it has for config is an inventory of
hardware devices. There's a certain elegance in simplicity
that would be lost trying to cover what should be a fairly
narrow use case.
Imagine all the debugging you have to do - is this job failing
because it is trying to use the config as it appears in the
config file, or some other config in memory from some time in
the past? What happens if we now have different device names
referring to the same physical device, we now need a whole
locking mechanism that can cover the use case of multiple
versions of the SD config accessing the same physical device,
possibly with different parameters and names. How would you
be able to tell which version of the config a given job is
using? Remember it is easy to start a backup job that can
last a couple of days - a full backup of a huge fileserver for
instance.
Things would get really messy really fast, with practically no
benefit. Your SD config likely changes what, once or twice
per year? If that? It is much safer to just restart the SD
when you have an idle period between backups.
Bryn