30, 2011 4:51 AM
To: Phil Mayers
Cc: bind-users@lists.isc.org
Subject: Re: Choosing max-journal-size
On 30/11/2011 10:32, Phil Mayers wrote:
> We sort of did this accidentally. "max-journal-size" wasn't being set on
> our servers - the .jnl file for "imperial.ac.uk" w
On Nov 30, 2011, at 4:09 AM, Matus UHLAR - fantomas wrote:
>> On 11/29/2011 11:33 PM, Chris Thompson wrote:
>> I wonder if an external tool to "trim" the journal would be an option? You'd
>> need a timestamp on records (relying on the RRSIGs mean it only works for
>> signed). Not sure about the
On 30/11/11 12:10, Matus UHLAR - fantomas wrote:
On 30/11/11 10:09, Matus UHLAR - fantomas wrote:
Well, that's way too much. The main point of journal is imho to provide
On 30.11.11 11:51, Phil Mayers wrote:
I think this is a decision for each operator to make themselves.
I was trying to ex
On Wed, Nov 30, 2011 at 11:09:48AM +0100, Matus UHLAR - fantomas wrote:
> Well, that's way too much. The main point of journal is imho to
> provide IXFR, and IXFR is only worth using when its size is smaller
> than AXFRs.
>
> That means jnl should not get (much) bigger than zone file itself.
> (un
In article ,
Matus UHLAR - fantomas wrote:
> >On 30/11/11 10:09, Matus UHLAR - fantomas wrote:
> >>Well, that's way too much. The main point of journal is imho to provide
>
> On 30.11.11 11:51, Phil Mayers wrote:
> >I think this is a decision for each operator to make themselves.
>
> I was try
On 30/11/11 10:09, Matus UHLAR - fantomas wrote:
Well, that's way too much. The main point of journal is imho to provide
On 30.11.11 11:51, Phil Mayers wrote:
I think this is a decision for each operator to make themselves.
I was trying to explain that there are reasonable limits over which
On 30/11/11 10:09, Matus UHLAR - fantomas wrote:
Well, that's way too much. The main point of journal is imho to provide
I think this is a decision for each operator to make themselves.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-use
On 30/11/2011 10:32, Phil Mayers wrote:
> We sort of did this accidentally. "max-journal-size" wasn't being set on
> our servers - the .jnl file for "imperial.ac.uk" was nearly 2Gb... oops.
>
> The value I set it to eventually was pretty big - 128M globally - which
> on our biggest zones seems to
On 11/29/2011 11:33 PM, Chris Thompson wrote:
With a mixture of small and large zones, signed and unsigned, choosing
sensible values for max-journal-size can become rather tedious (unless
one is prepared to to say "disc space is cheap, make them all ").
On 30.11.11 09:32, Phil Mayers wrote:
We
On 11/30/2011 01:23, Phil Mayers wrote:
> On 11/29/2011 11:53 PM, Doug Barton wrote:
>> On 11/29/2011 15:33, Chris Thompson wrote:
>>> With a mixture of small and large zones, signed and unsigned, choosing
>>> sensible values for max-journal-size can become rather tedious (unless
>>> one is prepare
On 11/29/2011 11:33 PM, Chris Thompson wrote:
With a mixture of small and large zones, signed and unsigned, choosing
sensible values for max-journal-size can become rather tedious (unless
one is prepared to to say "disc space is cheap, make them all ").
We sort of did this accidentally. "max-jo
On 11/29/2011 11:53 PM, Doug Barton wrote:
On 11/29/2011 15:33, Chris Thompson wrote:
With a mixture of small and large zones, signed and unsigned, choosing
sensible values for max-journal-size can become rather tedious (unless
one is prepared to to say "disc space is cheap, make them all").
I
On 11/29/2011 15:33, Chris Thompson wrote:
> With a mixture of small and large zones, signed and unsigned, choosing
> sensible values for max-journal-size can become rather tedious (unless
> one is prepared to to say "disc space is cheap, make them all ").
I'm quite prepared to say that, especiall
With a mixture of small and large zones, signed and unsigned, choosing
sensible values for max-journal-size can become rather tedious (unless
one is prepared to to say "disc space is cheap, make them all ").
What I would really like is an option that discards increments applied
sufficiently long
14 matches
Mail list logo