[bind10-dev] shared memory data source: file-based (mmap) vs memory-only

[Michal 'vorner' Vaner]

Hello

On Wed, Feb 27, 2013 at 09:05:01PM -0800, JINMEI Tatuya / 神明達哉 wrote:
> I personally prefer the file-based approach, because this can work as
> a persistent on-disk copy that enables nearly-zero (hot start case) or
> a few-to-10-ish seconds (cold start case, with some initial work) of
> start up time.  The major disadvantage is management overhead of the
> files and the risk of having corrupt on-disk images.
> 
> Do others have opinions/preferences on this?

The file-based one does seem to have some advantages here. So I think we could
use them. Only one thing ‒ I believe the memmgr (or how we'll call the process
managing the memory segments) should mostly auto-configure. I don't want to
force user to specify a filename for each zone being cached. I'd see that as
setting the directory where the images should reside and examine list of files
per zone, optionally with some commands (re-create data for this zone, remove
this no-longer used zone, etc).

But, I'm slightly worried about some embedded devices. They might have more RAM
than disk space and often rewriting the disk space doesn't seem right either.
Also, I don't know if the file-based approach might slow things down (imagine
you load the zone from DB to the image, then you are waiting for reads from the
DB and on the writes to the file).

Would it be very problematic to support both ways? Or, at least designing it
that most of the code could be reused when adding the second one?

> On a related note: I remember there was a mention of the use of
> copy-on-write when updating the current version of the shared memory
> image.  As far as I can see, we can't benefit from it, at least not if
> we use the above Boost utility classes.  We'll first need to make a
> complete copy of the current image, either on disk or in-memory and
> then updated the copied version.

That looks very unfortunate. Imagine a large zone, let's say the com. Doing a
copy when one small change comes is too slow (there are probably many changes
per minute and doing a complete copy would take more than a minute). Also, that
would take twice as much space (on disk or in memory).

I'm wondering if anything of this would work:
 • Open in auths in read-only or copy on write and hope the changes will not
   propagate until we map again.
 • Use some FS that uses copy-on-write internally.
 • Keep two copies all the time, one active and one inactive. Apply changes to
   the inactive, then switch. Then catch up (apply all the same changes to the now
   inactive one) and start applying new changes to it. This solves the speed,
   but not the size.

With regards

-- 
No one is to look like a sock, understand?
			-- Archchancellor Ridcully

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/20130228/082baccf/attachment.bin>