[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 12:34:42 Graham Keeling, vous avez écrit :
> On Thu, Dec 11, 2008 at 10:22:42AM +0100, Eric Bollengier wrote:
> > > I found that volumes would go through the Scratch pool, and be shared
> > > out among all the different storage daemons.
> > I'm quite suprised, we have also a StorageId that should prevent this
> > problem.
> > This is not perfect, but it should work in this situation.
> I have just tested this again with both bacula-2.2.8 and
> bacula-2.5.16-beta, and the StorageId does not prevent it happening, so I
> think that it is broken somehow.
> Perhaps because all the places that check StorageId are only doing so if
> InChanger=1. I don't think InChanger is ever 1 for me, because I am not
> using a disk changer.
Ok, i see
> > > So, my question is whether I am right in assuming that the
> > > ScratchPoolId on Pools was intended to be used this way (to indicate a
> > > pool to draw media from), or whether there is a reason (or reasons)
> > > that the implementation was not finished.
> > We were waiting for your patch :) It's a good idea to add database fields
> > for future use, that avoids schema upgrade between each release....
> > I've take a look of your patch, and i it looks quite good. (i've seen 2
> > small typo problems in sql_create.c (ed4) and in ua_update.c
> > (recyclepool))
> > But i think that your patch can be more simple, let me explain
> > I think that you want that a pool (dedicated to a storage) takes media
> > from a specific Scratch pool. So, it's a pool attribute. (We have the
> > ScratchPoolId field in the Media table, but it's not a reason to use it).
> > It's not like the RecyclePool attribute that is a Volume attribute (for
> > life). The ScratchPool is used to select a volume from a pool, and the
> > RecyclePool is used to put a volume in a pool.
> > If i'm not wrong and you are ok, can you cleanup your patch in this way ?
> 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.
The RecyclePool parameter is used from the pool only when you create a volume
The setup will look like this :
Name = Scratch1
RecyclePool = Scratch1
Name = Scratch2
RecyclePool = Scratch2
Name = Default
ScratchPool = Scratch1
Name = Full
ScratchPool = Scratch2
I prefere keep the ScratchPool usage. (waiting for other comments)
> I will send my patch for this, which applies to SVN revision 8139, as soon
> as I have confirmed with my office that the FSFE form has been sent.
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.