[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] Multiple storage daemons - multiple scratch pools?


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
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.

> > 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 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.