[bind10-dev] take 2: design and inter-process protocol for shared memory

[Michal 'vorner' Vaner]

Good morning

On Thu, Mar 14, 2013 at 11:07:46AM -0700, JINMEI Tatuya / 神明達哉 wrote:
> (The original response was unicasted again, but I believe it wasn't
> intentional, so I'm cc'ing the list in this response.)

Crap. I'll have to make the email client ask me if I really do want to unicast
the message, or something.

> At Thu, 14 Mar 2013 09:20:03 +0100,
> Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:
> 
> >  • We don't really need the _latest_ state in the mapped file. If the data
> >    source contains journal, we can just ask for the diff from the version in the
> >    file and the newest when updating (which we should do anyway, there can be
> >    more than one change between the manager has time to do full update) and the
> >    old version is available in the file (at least by the SOA, but we could store
> >    it somewhere separately).
> > 
> >    If the data source does not have journal, then we need to rebuild from
> >    scratch every time anyway, and we don't care what was the previous version.
> > 
> >    But I don't mind having an explicit „rebuild“ command.
> 
> Is this about Section 5.7?  If we always build all zones on the mapped
> file (or apply outstanding diffs) on startup, you're right, this is
> not an issue.  But I wanted to minimize the startup time as much as
> possible when it's actually possible.  If the file to map already
> contains the latest versions of the zone, the initialization can be
> just done by mmap().

Yes, about 5.7. The memmgr maps them at startup to check they work.

If the concern is to start up as fast as possible, we could do this:
 • Map read only in manager, to see it has the right structure, or something.
 • Map in readers.
 • Look into version of each zone in database and compare with the one in the
   file. Remember list of zones that need rebuild.
 • Unmap the first one from manager.
 • Map the second, compare the versions again (because the two files don't
   necessarily have to be at the same version), unify the lists.
 • Apply changes to all the zones.
 • Switch the files.

> >  • Can mapping of the file fail? What happens, then? Do we abort? Do we complain
> >    to manager and keep the old version?
> 
> In theory, it can.  But at least for readers, I think we can
> reasonably assume it's very unlikely to fail as the manager should
> have successfully mapped it just before that, so it would be
> reasonable to consider any failure fatal.  For the manger, I think
> it's okay to begin with treating it as fatal, too, but I think we'll
> later have to make it more robust, e.g., by trying to remove any
> existing file and creating a new image from the scratch.

OK. So we don't have to care about the case where the reader sends a NAK (can't
map this one, keeping the old) to the manager.

With regards

-- 
No, I will not change your lightbulb.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20130315/7a25cdc2/attachment.bin>