[kea-dev] Fwd: Logging leases to memfile

Tomek Mrugalski tomasz at isc.org
Fri Oct 21 10:10:32 UTC 2016


W dniu 21.10.2016 o 02:24, Victoria Risk pisze:
>> Good afternoon,
Hi Judy,
Sorry to hear about your issues with using kea-dev. Hopefully they're
now resolved.

>> In kea-dhcp-server, I do not see any code to synchronize the lease
>> file with storage device. Is that true or I missed something? If that
>> is true, any rational (besides performance concern) behind this?
Yes. Kea does not explicitly call fsync. The performance was the primary
reason, but not the only one.

When RFC2131 was published in 1997, hardware failures were more common,
so the text explicitly tells the server to commit the lease information
to persistent storage and then respond. That's bullet 4 in Section 3.1
of that RFC. Now, couple years later RFC3315 that defines DHCPv6
operation was published. It does not make such a requirement any more.

This is also what most people are expecting these days. We have heard
lots of inquiries about performance, but very rarely we see any request
for fsync. I can only speculate why. Probably because things have
changed dramatically over the years. If you had 'a large network' in
1997, you probably meant something like 200 desktops. How much DHCP
traffic that would generate? Now, back to 2016, when someone says 'a
large network' I'm wondering how many millions he has in mind.

On a related note, DHCPv4 has a mechanism that lets the server ping the
address to be leased, wait a second and only then respond back. Such a
mechanism would be a head scratcher in DHCPv6. Nowadays people are
optimizing their solutions to shave off extra milliseconds in the
processing and try to serve hundreds more leases each second.

Finally, there's the time perspective argument. ISC DHCP development
started in 1995. It's over 2 decades old. We're hoping that Kea would be
equally long lived. I seriously hope the IPv6 migration will finally be
complete by then, so we tend to favor the DHCPv6 perspective over DHCPv4.

So these are the reasons why we haven't implemented explicit fsync call
yet. We will likely to do it one day, but it's a matter of priorities.
Kea is being developed by a small team that receives a lot of requests,
so we need to prioritize. When we get to this particular issue, it's
almost certain the default will be as it is now and the switch would be
use-fsync.

Hope that helps,
Tomek



More information about the kea-dev mailing list