<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
-------- Original Message --------<br>
Subject: Re: Watching performance on a DHCP Server<br>
From: David W. Hankins <a class="moz-txt-link-rfc2396E" href="mailto:David_Hankins@isc.org"><David_Hankins@isc.org></a><br>
To: <a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@isc.org">dhcp-users@isc.org</a><br>
Date: Friday, February 08, 2008 4:53:15 PM<br>
<blockquote cite="mid:20080208225315.GE26411@isc.org" type="cite">
<pre wrap="">On Fri, Feb 08, 2008 at 03:27:23PM -0600, Blake Hudson wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Seems like it would make sense that this I/O could be non-blocking....
</pre>
</blockquote>
<pre wrap=""><!---->
That's just it, we feel it can't be, or else you run the risk of
duplicate allocations on a restart. The simple way of saying it is
the database isn't consistent.
It's the same sort of thing that makes an e-commerce system want to
'SQL COMMIT' before replying down an http socket that an order has
gone through. If you crash and need to recover data from disk, you'd
rather have the customer's money and order than an order number that's
a duplicate for some other customer because your system walked over it
when it came back up.
Same deal; we deal in leases which are a lot like transactions. A
promise is made that an address is good for a given time. Money may
not change hands, but things break if you reneg, things work if you
delay or even drop the request waiting...the far end retransmits.
I don't mind it being configurable behaviour, heck all you have to do
is comment out a single line and rebuild the sources if you were
intent on it, but we haven't got a patch for that.
</pre>
</blockquote>
I was thinking about that [patch] while composing my last message. I
truly appreciate your time and expertise in this matter.<br>
<br>
The pros of fsync are that I can say I will never lose a lease
(assuming my disks don't die, RAID controller doesn't die, file system
doesn't corrupt, RAM doesn't go bad, server doesn't hit the bricks,
etc). The downside is that I have to spend twice as much on server
hardware to handle the increased load (or build a custom workaround
such as tempfs that could lead to loss of a lot more data) and still
may end up with less capacity compared to an async setup.<br>
<br>
The pros of async are that I can spend much less on server hardware,
the cons being that I might lose 5 seconds (default commit time for
ext3) of leases (single digits?) if my server were to freeze (again
making the same assumptions about hardware failure).<br>
<br>
There are a lot of things that can go wrong with a server (or network
for that matter). From a practical perspective, the thought of losing 5
seconds of leases in server lockup is a non-issue to me (and probably
others). If I had the choice of penalizing every request, versus
penalizing a few requests in several years time I would choose the
later.<br>
<br>
I'd love to see this available as an option left up to the server
administrator. I'll take a gander at the source next week and see
exactly what it might take. Any changes I make will probably not be as
useful as I'd prefer to stick with the src rpm provided by my
distribution (Fedora), which is currently 3.0.x based.<br>
<br>
Thanks again,<br>
-Blake<br>
</body>
</html>