Incremental Updates

[Erik Rozendaal]

Peter A. Friend wrote:
> 
> Well as an example, parsing and building that database for over  
> 300,000 zones can take an hour, so just making a change to one zone  
> isn't possible, and has to wait for the next build. 

Is this with NSD 2.3.0? Kazunori Fujiwara provided us with a patch that 
speeds up zonec a lot when many zones need to be parsed. This patch is 
part of 2.3.0.

> What would be  
> ideal is to be able to take an existing built database, parse the  
> zone files that have changed, and update the database. I have looked  
> at the code, and the problem I have is that there is no way to free a  
> pointer within a region, and I also don't see any delete routines for  
> the red black tree stuff. This leaves stuffing the records into their  
> existing entry (for a zone that was already in the database), and I  
> haven't figured out a safe way to do that yet. Once the "diff" is  
> applied, then the database file can be written out again, and  
> reloaded by nsd.

Regions were implemented so everything that needs to be free'd together 
is allocated into a single region. This helps performance and makes the 
logic for free'ing large amounts of data simpler. So if parts of can be 
free'd earlier you should use a separate region and free that.

Another approach you can consider (if 2.3.0 zonec is still too slow) is 
to modify NSD so it can load multiple databases on startup and compile 
every zone (or some grouping of zones) into separate .db files.

Of course, with this modification NSD will still have to read in all the 
.db files.  But hopefully that will be fast enough.

Erik