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

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

Hello Graham,

Thanks for the patch.  We will take a careful look at it.

In the mean time, would you please fill out two copies of the FLA and mail 
them into the Zurich office, then let me know when you have done so.  See 
www.bacula.org -> FSFE License



On Monday 24 November 2008 11:02:27 Graham Keeling wrote:
> Hello,
> Using bacula-2.2.8 (though I've had a brief look at SVN, and it seems the
> same)...
> 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.
> I found that volumes would go through the Scratch pool, and be shared out
> among all the different storage daemons. 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
> location.
> 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. It seems more elegant than needing to give a different
> Media Type for every different storage.
> Graham.

This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Bacula-devel mailing list

This mailing list archive is a service of Copilotco.