[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] Multiple storage daemons - multiple scratch pools?
Le Monday 24 November 2008 11:02:27 Graham Keeling, vous avez écrit :
> Using bacula-2.2.8 (though I've had a brief look at SVN, and it seems the
So, please, provide your patch against the current trunk... We need also a
documentation patch for this feature. You can send it to me in a text format
if you are not a LaTeX user. A regress script that tests all new options is
> I configured bacula with a single storage daemon, using disk file volumes.
> I configured my pools to have RecyclePool = Scratch, with the intention
> that the volumes would be recycled throughout all of the pools.
> Eventually, I got this working, so I went on to the next step - having
> multiple storage daemons in different locations.
One advise maybe, use different MediaType for each location, and bacula will
do the work...
> 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.
> The effect would be that a file
> would be left on disk in one location, whilst a new version of it would
> appear in another.
> This was clearly because I was using a global Scratch pool.
> What I would like to do is set up an individual Scratch pool for each
> of my storage devices, so that the media in one location stays in that
> After looking at the bacula code, it seems to me as if the configurable
> Scratch pool feature was planned and it has nearly been implemented.
> It is possible to set 'Pool Type = Scratch' in a Pool, and 'ScratchPoolId'
> is a database field on Pools and Media - though it is always set to 0. The
> current 'RecyclePoolId' tells media where they should go when they are
> recycled, but Media are only drawn from the Pool specifically named
> 'Scratch'. I've even come up with patches to the (2.2.8) code that seem to
> have the ScratchPoolId working in the way that I assume it was intended.
> 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....
> It seems more elegant than needing to give a different
> Media Type for every different storage.
I'm agree, but it works well, and permit to share pool, scratch etc...
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 ?
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.