Choosing max-journal-size

[Phil Mayers]

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. "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 months of history. This is almost 
certainly overkill of a huge magnitude, but disk is relatively cheap!

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, signed 
zones.

> 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.