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 was nearly 2Gb... oops.
The value I
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
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 BIGNUM).
We sort of did this accidentally.
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 prepared to to say
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 BIGNUM).
On 30.11.11 09:32, Phil Mayers
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 give ~2
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
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
In article mailman.403.1322655086.68562.bind-us...@lists.isc.org,
Matus UHLAR - fantomas uh...@fantomas.sk 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
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.
(unless,
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
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 locking
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 BIGNUM).
What I would really like is an option that discards increments applied
sufficiently
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 BIGNUM).
I'm quite prepared to say that,
14 matches
Mail list logo
