[bind10-dev] recover from memmgr restart

[JINMEI Tatuya / 神明達哉]

At Thu, 13 Jun 2013 08:53:55 +0200,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> > "In the 3rd diagram of Section 5.1" referenced in the above URL, it's
> > implicitly assumed "auth-1" doesn't use any mapped file or
> > zone-mapped.1, but it's not guaranteed.  It may have been using
> > zone-mapped.0, in which case the memmgr wouldn't even make initial
> > updates to it in the first diagram.  Also, depending on the timing of
> > the previous termination of memmgr, there can even be multiple reader
> > processes using different mapped files (e.g., if the memmgr died in
> > the middle of sending update messages).  So we'll need more explicit
> > synchronization.
> 
> Hmm. I think I see the problem. Is it that this will not allow the manager to
> open either in read-write mode?

If you are asking: in the first diagram of
http://bind10.isc.org/wiki/SharedMemoryIPC#a5.1.InitialStartup
what if auth-1 has actually been using zone-mapped.0 (and memmgr has
restarted without knowing it), then, yes, map(RW) will fail.  The
MemorySegmentMapped class uses an advisory lock to detect such
programming errors.  Even if it's somehow allowed, it will cause some
undesirable results (depending on the system's mmap implementation
details) as both the writer and a reader will be using the same image
without any synchronization.

> > There can be several ways to address this issue, but I'd suggest
> > maybe-suboptimal but simpler solution: when memmgr starts up, it tells
> > all pre-existing readers to clear all segments they are using (if
> > any).  When memmgr will get acknowledgments from all such readers, it
> > can now start making initial updates.
> 
> I think we can have a less painful solution (not dropping queries) for only
> slightly more complicated (or, maybe even less complicated) solution.
> • When the manager starts doing updates to the image, it adds a mark to it (for
>   example by pushing a named pointer into there).
> • It does the updates.
> • Removes the mark.
> 
> Then, upon start, the manager maps both images (if they exist) read-only (which
> should be possible, auths only read). It picks one that has no mark (eg. is not
> in the middle of updates) and is the newest such (has the biggest SOA, for
> example).

Hmm, this seems to be workable.  We'd probably implement it as
follows:
- introduce the concept of "dirty" ZoneTableSegment.  Applications
  will know if the cache segment (if used) is dirty by examining the
  return value of getStatus() (we'll extend it)
- For the mapped version of ZoneTableSegment, we mark it as dirty when
  opening it in the read-write mode by creating some named address in
  the underlying memory segment.  This address will be removed when we
  close that segment.
  Then, we consider the ZoneTableSegment dirty if:
  - it's opened in the read-write mode, or
  - it's opened in the read-only mode but has that name of address.

The memmgr can then determine the latest readable version by choosing
the newest (if there are several) non-dirty files.

---
JINMEI, Tatuya