Matus UHLAR - fantomas
uhlar at fantomas.sk
Wed Nov 30 10:09:48 UTC 2011
>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 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...
>The value I set it to eventually was pretty big - 128M globally -
>which on our biggest zones seems to give ~2 months of history. This
>is almost certainly overkill of a huge magnitude, but disk is
>Not sure how many zones you've got, but we've got ~300 and our total
>"zones/" subdir size is ~1.2Gb - most of that is several large,
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, of course, always the same data gets added/removed/changed).
>>What I would really like is an option that discards increments applied
>>sufficiently long ago - the expire time for the zone being an obvious
>>choice. But I do see that the current structure of the journal file
>>would make that hard to implement.
>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 implications.
I think this is something BIND should take care about.
Does BIND veridy the journal not to exceed usefull size?
Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam is for losers who can't get business any other way.
More information about the bind-users