Kern Sibbald a écrit :
On Monday 10 April 2006 17:29, Ryan Novosielski wrote:
John Kodis wrote:
On Mon, Apr 10, 2006 at 11:59:15AM +0100, Alan Brown wrote:
If there are recyclable pool volumes in the changer then use them, else
use available scratch pool volumes.
Otherwise the size of a tape pool can effectively grow far more rapidly
than expected in the absence of a "max volumes =" pool parameter.
I'd second this. I'd like to be able to leave a number of scratch
volumes available without having them put into service when there are
other eligible volumes available.
I'd like to add a third. I don't use scratch pools at all, currently,
but I can't see why I'd want a new volume being added to the pool when
I've got one in there that's supposed to be used. Wouldn't that mean
that it would ALWAYS choose a scratch volume if there is one available
and all of your tapes are full (even if one should be recycled)? In my
setup, this would be the case anyway.
If I remember the argument correctly, it was: "Why overwrite volumes if there
are scratch volumes available? That is what scratch volumes are for."
Hello,
In my opinion, the pools should normally cycle on theirs tapes without
adding tapes in a stable situation. The scratch pool should be a
security to avoid blocking the backups if one volumetry's job increases
suddenly, for example.
The second advantage of scratch pool is to reach a stable situation
automatically : I create all my pools, I put all the tapes in the
scratch pool, and let's run Bacula and see what happen. The pools will
pick the tapes until they can cycle respecting the retentions periods,
so the different pools should be stable.
With the new algorithm, I can't use the scratch pool in any of these ways...
So please Kern, "put it back to the 1.38.5 behavior" !
Ludovic Strappazon.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
