On Friday 14 April 2006 22:04, Bennett, Silas (GE Indust, Security) wrote:
> Hi Kern,
>
> I did not intend for my emails to be read as complaints.
I don't really mind complains, and in fact, my response was a complaint :-)
> Bacula works
> _Very_ well for me, and I am very grateful for the work that you do. My
> intent was to essentially submit bug reports against the docs. Is it the
> case that the Scratch Pool just doesn't work in 1.36?
I don't believe the Scratch Pool was implemented in 1.36. There were a few
minor bugs in the first releases of 1.38, but nothing that I remember being a
total show stopper.
> If that is the case,
> simply modifing the docs as such would clear things up a bit:
There *should* be no mention of the Scratch Pool in the 1.36 document, so this
issue should not come up. I suppose someone could have created a Scratch
pool in 1.36, but other than the fact that things would work a bit
differently in 1.38.x, I don't see any major problem with having a pool with
the name Scratch prior to 1.38, and I don't understand why it would hinder an
upgrade.
>
> ORIGINAL:
>
> <H3><A NAME="SECTION0001410100000000000000">
> The Scratch Pool</A>
> </H3>
> <A NAME="6959"></A>
> <A NAME="6960"></A>
> In general, you can give your Pools any name you wish, but there is one
> important restriction: the Pool named <B>Scratch</B>, if it exists behaves
> like a scratch pool of Volumes in that when Bacula needs a new Volume for
> writing and it cannot find one, it will look in the Scratch pool, and if
> it finds an available Volume, it will move it out of the Scratch pool into
> the Pool currently being used by the job.
> <P>
>
> MODIFIED:
>
> <H3><A NAME="SECTION0001410100000000000000">
> The Scratch Pool</A>
> </H3>
> <A NAME="6959"></A>
> <A NAME="6960"></A>
> In general, you can give your Pools any name you wish, but there is one
> important restriction: the Pool named <B>Scratch</B>, if it exists behaves
> like a scratch pool of Volumes in that when Bacula needs a new Volume for
> writing and it cannot find one, it will look in the Scratch pool, and if
> it finds an available Volume, it will move it out of the Scratch pool into
> the Pool currently being used by the job. Note that the Scratch pool does
> not work properly for versions prior to {INSERT VERSION IN WHICH IT IS KNOW
> TO WORK HERE}, but it is still recommended that you not use the Scratch
> pool in prior versions for anything else as it will hinder your upgrade
> path.
> <P>
>
>
>
> Regaurding my previous email, on the migration from SQLite to MySQL, I
> don't have enough knowledge of the intricacies of SQLite or MySQL to
> propose a proper migration solution. But I will attempt to put together a
> documentation change that will point the reader in the right direction. I
> will send this in a seperate email.
I've modified the document in that area simplifying the text letting the user
know that the process is not so simple. The new document should be up
tomorrow.
Regards,
Kern
>
>
> -----Original Message-----
> From: Kern Sibbald [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 14, 2006 12:06 AM
> To: bacula-users@lists.sourceforge.net
> Cc: Bennett, Silas (GE Indust, Security)
> Subject: Re: [Bacula-users] Scratch Pool Question
>
> On Friday 14 April 2006 04:08, Bennett, Silas (GE Indust, Security) wrote:
> > Hi All,
> >
> > This is a follow up to my SQLite -> MySQL migration Email.
> >
> > The Scratch Pool has _NEVER_ worked for me, and during the database
> > migration, I noticed something.
> >
> > In the Pool Table there is a field called ScratchPoolId, and all of the
> > records in the table have ScratchPoolId set to 0. What is the purpose of
> > ScratchPoolId, can I set that to the PoolId value of the Scratch Pool and
> > make stuff work? Is there any configuration file directives to put into
> > the Pool resource definitions to tell it which scratch pool to use?
> >
> > The Docs are again a bit thin here.
>
> The ScratchPoolId is not used, so don't worry about it (at least not yet).
> I don't have time to document all the technical details, so the docs are
> going to remain very thin in that regard for a long time.
>
> However, in the case where someone has specific knowledge of the
> deficiencies of the manual, it would be more useful to complain and at the
> same time send me suggested new text rather than throw the work back on me
> as is the case 95% of the time.
--
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
