[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] Multiple storage daemons - multiple scratch pools?
Le Thursday 11 December 2008 14:17:09 Robin O'Leary, vous avez écrit :
> On Thu, Dec 11, 2008 at 01:29:48PM +0100, Eric Bollengier wrote:
> > Le Thursday 11 December 2008 12:34:42 Graham Keeling, vous avez écrit :
> > > Since sending my original patch, we came up with a slightly different
> > > idea that required much less change to the code, and is therefore
> > > likely to be safer. I am currently using this new idea instead of the
> > > original one.
> > >
> > > It goes like this:
> > > If Pool A needs a volume and has a RecyclePoolId is pointing to a Pool
> > > B that is of type 'Scratch', then Pool A can take a volume from Pool B.
> > > If it was unable to do that, it falls back to trying to take a volume
> > > from the pool named 'Scratch'.
> > > When it is autopruning, it can cause volumes with a RecyclePoolId
> > > pointing to the same Scratch Pool as the current Pool's RecyclePoolId
> > > to be pruned/purged and moved into that Scratch Pool.
> > I'm not sure that it is a good idea, RecyclePool and ScratchPool are two
> > different things. We can see that like a cycle.
> Note that Graham said the suggested new behaviour is only triggered if you
> define the pool targetted by RecyclePool as having Pool Type = Scratch.
> If you leave it as an ordinary Backup pool, as it would be in your example,
> the behaviour is the same as before.
I found this not very simple, try to write the manual part that will explain
that. And it links together two different things (RecyclePool and
ScratchPool). I still think that the previous Pool->ScratchPool directive is
the most simple. Easy to explain, easy to use.
> The existing behaviour for the recommended RecyclePool = Scratch set-up
> is also preserved by this change. At the moment, the scratch pool is
> magic because it is named 'Scratch', but after the change, it behaves
> in this special way because it is Pool Type = Scratch, which seems rather
> more obvious.
I don't think that it's time to use PoolType field, not for this application
or not like that.
> In fact, if we could be sure people followed the documentation, we
> could remove any special handling of the pool name 'Scratch' entirely.
> However, this would change the behaviour of existing configurations
> that use RecyclePool = Scratch but declare the Scratch pool to have
> Pool Type = Backup. Although that's not the documented way to do it,
> the Pool Type doesn't seem to matter, so people could be doing that wrong
> and not notice. Hence Graham's change keeps the special behaviour of
> the name 'Scratch' as a fall-back.
In any cases, we have to keep the Scratch pool as it is, and Graham patch is
pretty cool for that (Pool.Name = Scratch, PoolId = ScratchPoolId in
Thanks for comments
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
Bacula-devel mailing list
This mailing list archive is a service of Copilotco.