dont-use-fsync real world impact

Jure Sah e at juresah.si
Sat Sep 28 11:33:50 UTC 2019


On 27. 09. 19 19:46, Simon Hobson wrote:
> It's my understanding that the fsyncs are to ensure that the data has been committed to permanent storage BEFORE the lease is offered to a client - as required by the DHCP RFCs. Atomic writes aren't really an issue - I strongly suspect that the server builds a whole lease file record in the buffer and passes that in one write operation, and if that's the case, then the only non-atomic write issue would be if multiple writes were made (without fsync) such that lease file records cross a disk buffer boundaries.
> If a lease file entry were truncated, then I believe the server can deal with this on startup by discarding the incomplete record.
>
> So yes, ensuring atomic writes is a by-product of using fsyncs - but not (in this case) the primary reason.

I see, so if theoretically the DHCP server could work in such a way as
to "fsync asynchronously" (oxymoron I know), in that the lease could be
written to disk before it is offered to the client, but not necessarily
before the next lease could be served, then this would adhere to the
RFC, represent no real performance penalty, while also not limiting the
rate at which requests can be served.

What changes would be required for this to work? A memory pool of
offered IP addresses which are not to be assigned to new clients?
Rotating a pool of physical disks to store leases in? Multiple
synchronised DHCP servers?

I am just trying to find a solution to this problem that is infinitely
scalable.

LP,
Jure




More information about the dhcp-users mailing list