Send kea-dev mailing list submissions to
        kea-dev@lists.isc.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
        kea-dev-requ...@lists.isc.org

You can reach the person managing the list at
        kea-dev-ow...@lists.isc.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."


Today's Topics:

   1.  Fwd: Logging leases to memfile (Victoria Risk)
   2. Re:  Fwd: Logging leases to memfile (Tomek Mrugalski)


----------------------------------------------------------------------

Message: 1
Date: Thu, 20 Oct 2016 17:24:19 -0700
From: Victoria Risk <vi...@isc.org>
To: kea-dev@lists.isc.org
Subject: [kea-dev] Fwd: Logging leases to memfile
Message-ID: <0ba56186-ba24-42be-94fa-bd6257171...@isc.org>
Content-Type: text/plain; charset="utf-8"


> From: Judy Hao 
> Sent: Thursday, October 20, 2016 2:27 PM
> To: 'kea-dev@lists.isc.org <mailto:kea-dev@lists.isc.org>' 
> <kea-dev@lists.isc.org <mailto:kea-dev@lists.isc.org>>
> Cc: 'j...@brocade.com <mailto:j...@brocade.com>' <j...@brocade.com 
> <mailto:j...@brocade.com>>
> Subject: Logging leases to memfile
>  
> Good afternoon,
>  
> 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?
>  
> In isc-dhcp-server, there is a statement ?dont-use-fsync? in dhcpd.conf, 
> which instructs DHCP server if it should call fsync() when writing leases to 
> the lease file.
>  
> Thanks,
> Judy 




-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<https://lists.isc.org/pipermail/kea-dev/attachments/20161020/02448548/attachment-0001.html>

------------------------------

Message: 2
Date: Fri, 21 Oct 2016 12:10:32 +0200
From: Tomek Mrugalski <tom...@isc.org>
To: kea-dev@lists.isc.org
Subject: Re: [kea-dev] Fwd: Logging leases to memfile
Message-ID: <52f5c3b5-b935-542d-8696-b1be3b58b...@isc.org>
Content-Type: text/plain; charset=windows-1252

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



------------------------------

Subject: Digest Footer

_______________________________________________
kea-dev mailing list
kea-dev@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-dev

------------------------------

End of kea-dev Digest, Vol 31, Issue 5
**************************************

Reply via email to