[Dnsmasq-discuss] How does DNSMASQ handle large concurrent configure file updating request requests

[Yongkang You]

On Fri, Jan 16, 2015 at 7:24 PM, Simon Kelley <simon at thekelleys.org.uk>
wrote:

> Here's one possible solution.
>
> dhcp-hostfile can take a directory instead of a filename, so instead
> of having one  file with 40k lines in it, have a directory with a file
> for each host. (Aside, 40k files is a big directory, but it can be
> split into multiple directories, if needed). By itself, this will go
> backwards, since opening 40k small files to read them all will be even
> slower, so we need an addition to dnsmasq.
>

Yeah, this could resolve the incomplete config file issue. But the slower
issue is also bad.


>
> The addition to dnsmasq is to use inotify to detect when a file is
> added or written. The development branch of dnsmasq already has code
> to do this for resolv files. With this change, there's no need to us a
> signal, and no need to re-read all the files. When a file appears in
> the directory or is modified _and_is_closed_ dnsmasq will wake up and
> read just that file. Much better, this fixes the race condition too.
>

It is very impressive!


>
> The simple way to implement this simply adds new configuration from
> new files, if a file gets changed or deleted, then the dhcp-hosts that
> were created by its old contents are not deleted, and SIGUSR1 is still
> needed to re-read the config from scratch and garbage collect old
> entries. More complex implementation would keep track which dhcp-hosts
> are associated with which files, and delete old versions when a file
> changes. I'd rather not have to do the more complex version, is it can
> be avoided.
>
> Comments?
>
>
Thanks Simon! I will currently use some workaround and wait for the super
inotify solution.

-- 
Yongkang You
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20150117/0c58f699/attachment.html>