[bind10-dev] Multicore Auth

[Evan Hunt]

> There seems to be another disadvantage: difficulty in implementing dynamic
> updates. One method is to reload at a time of receiving dynamic update
> requests, but it is much expensive.

Back in the very early BIND 10 discussions in late 2007 IIRC, we had a
conversation about an idea for rapidly loading an in-memory database via
mmap().  The notion was essentially to have most of the database be kept
in a large, read-only shared memory object, which could be loaded directly
from disk by the name server when launching.  There would be a separate,
smaller, writable shared memory area, probably a circular buffer, into
which dynamic updates would be written, kind of like an in-memory journal.
(IIRC, the assumption was that there would be separate processes processing
queries and updates, but that isn't necessary.)

Since the big database wouldn't be changing often, there's no need to worry
about locking it.  Since the journal is always being written forward into
unused memory, locking that is fairly straightforward.

There would be an external process that periodically rolled the journal
contents into a new copy of the database, and then sent a message to the
authoritative servers to all release the old version of the database and
attach to the new one.

At the time we discussed this, the point was to allow mmap() based loading
of the database, but it strikes me now that even if you didn't bother with
that part, this would still be a good general approach to a shared-memory
database that supports dynamic updates.

                                        eh