[3158] in Kerberos-V5-bugs
Re: krb5-libs/787: Replay cache code shouldn't call fsync() after every entry is written
daemon@ATHENA.MIT.EDU (tytso@MIT.EDU)
Mon Nov 29 14:26:32 1999
Date: Mon, 29 Nov 1999 14:25:11 -0500
Message-Id: <199911291925.OAA04230@trampoline.thunk.org>
To: jik@kamens.brookline.ma.us
Cc: krb5-bugs@MIT.EDU, krb5-unassigned@RT-11.MIT.EDU,
gnats-admin@RT-11.MIT.EDU, krb5-prs@RT-11.MIT.EDU
In-Reply-To: <199911232151.QAA21023@jik2.kamens.brookline.ma.us> (message from
Jonathan Kamens on Tue, 23 Nov 1999 16:51:58 -0500)
From: tytso@MIT.EDU
Date: Tue, 23 Nov 1999 16:51:58 -0500
From: Jonathan Kamens <jik@kamens.brookline.ma.us>
The replay cache code shouldn't call fsync() after every entry
is written into the replay cache. There's no point to it, and
it significantly hurts performance and thrashes the disk
unnecessarily when a server is receiving a lot of requests.
There's no question that having the replay cache call fsync() causes
disk activity. The original reasoning behind this was that most of the
time servers aren't making huge numbers of authentications per second,
and the furthermore, the server should be protected against replays in
case of server crash.
Of course, it's all a tradeoff; on systems with journalled filesystems
(so the fsck time can be avoided), a system can reboot faster than the 5
minute clock skew allowance. Then again, these circumstances don't
happen that often; so perhaps for some applications, not calling fsync()
is the right thing. It's not so obvious to me that fscync() should
*always* be avoided, though.
- Ted
