Dear Folks,
We have had problems with dhcpd 3.0.4 in a failover pair being unable
to resume normal communication after the long pause while it rewrites
the leases file, which is about 250MB in size.  We have some large
systems here at Optus.

I aim to implement a scheme proposed by my colleague to avoid the need
for dhcpd to stop and rewrite the leases.  Here is an outline of the
plan:

1. dhcpd starts up and reads its dhcpd.leases file.
2. At the end of this is a new top-level statement:

next file "dhcpd.leases.m";

   where m is a number (I will probably use seconds since the epoch)
3. dhcpd server then opens file dhcpd.leases.n, and reads that into
   memory.  It too may or may not conclude with a "next file" statement.

The arrangement would be like a linked list of dhcpd.leases files.
Here is a sort of picture of the scheme:

dhcpd.leases ------> dhcpd.leases.m -----> ... -----> dhcpd.leases.n

Now instead of stopping to rewrite the leases file, the server ends
the current dhcpd.leases file with a "next file" statement and starts
a new dhcpd.leases.n file.  The server never rewrites the leases file,
so does not need to stop serving leases, and does not need to
disconnect from its failover partner.

At the same time, a separate process reads the leases files up to the
last one that is not actively being written by the dhcpd server.

It consolidates them into a temporary file, say dhcpd.leases.tmp,
finishing it with a "next file" statement that points to the file that
was actively being written by the dhcpd server.  When that
consolidation process is completed, this external process renames the
temporary file to dhcpd.leases.

I would like this scheme to be accepted into the ISC dhcpd server, and
would like some feedback about it, and possibly get some suggestions
from dhcpd hackers.

Does anyone have any suggestions about implementation of the scheme
above?
-- 
Nick Urbanik http://nicku.org  x-71011 nick.urbanik@optusnet.com.au
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24