On Monday 10 April 2006 18:07, Ludovic Strappazon wrote:
> 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" !
Yes, my original reaction to the request to change the algorithm was more or
less what you write: if you have your retention periods and the number of
volumes setup correctly, Bacula shouldn't really need to pull from the
scratch pool except when it is going to block.
So either I incorrectly implemented what they wanted, or quite possibly they
(as I) didn't realize all the ramifications that such a change would have.
If there are still any users that want to keep the current behavior, you
should speak up now ...
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
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
