From jik@kamens.brookline.ma.us  Tue Nov 23 16:51:56 1999
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id QAA02254 for <bugs@RT-11.MIT.EDU>; Tue, 23 Nov 1999 16:51:55 -0500
Received: from nautilus.shore.net by MIT.EDU with SMTP
	id AA05127; Tue, 23 Nov 99 16:52:28 EST
Received: from jik.shore.net [206.243.167.15] 
	by nautilus.shore.net with esmtp (Exim)
	for krb5-bugs@mit.edu
	id 11qNqh-0002Z9-00; Tue, 23 Nov 1999 16:51:43 -0500
Received: from jik2.kamens.brookline.ma.us (IDENT:root@jik2.kamens.brookline.ma.us [192.168.0.3])
	by jik.shore.net (8.9.0/8.9.0) with ESMTP id QAA21171
	for <krb5-bugs@mit.edu>; Tue, 23 Nov 1999 16:51:06 -0500
Received: (from jik@localhost)
	by jik2.kamens.brookline.ma.us (8.9.3/8.9.3) id QAA21023;
	Tue, 23 Nov 1999 16:51:58 -0500
Message-Id: <199911232151.QAA21023@jik2.kamens.brookline.ma.us>
Date: Tue, 23 Nov 1999 16:51:58 -0500
From: Jonathan Kamens <jik@kamens.brookline.ma.us>
Reply-To: jik@kamens.brookline.ma.us
To: krb5-bugs@MIT.EDU
Subject: Replay cache code shouldn't call fsync() after every entry is written
X-Send-Pr-Version: 3.99

>Number:         787
>Category:       krb5-libs
>Synopsis:       Replay cache code shouldn't call fsync() after every entry is written
>Confidential:   yes
>Severity:       non-critical
>Priority:       medium
>Responsible:    krb5-unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   unknown
>Arrival-Date:   Tue Nov 23 16:52:00 EST 1999
>Last-Modified:  Mon Nov 29 14:27:01 EST 1999
>Originator:     Jonathan Kamens
>Organization:
	
>Release:        krb5-1.1
>Environment:
	
System: Linux jik2 2.2.12-20 #14 Thu Nov 18 20:57:02 EST 1999 i686 unknown
Architecture: i686

>Description:
	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.
>How-To-Repeat:
	
>Fix:
Index: ./src/lib/krb5/rcache/rc_dfl.c
--- rc_dfl.c	1999/11/23 20:50:58	1.1.1.1
+++ rc_dfl.c	1999/11/23 21:36:37	1.3
@@ -532,13 +532,6 @@
     {
    return krb5_rc_dfl_expunge(context, id);
     }
-#ifndef NOIOSTUFF
-    else
-    {
-	if (krb5_rc_io_sync(context, &t->d))
-	    return KRB5_RC_IO;
-    }
-#endif
  return 0;
 }
 
>Audit-Trail:

From: tytso@MIT.EDU
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
Subject: Re: krb5-libs/787: Replay cache code shouldn't call fsync() after every entry is written
Date: Mon, 29 Nov 1999 14:25:11 -0500

    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
>Unformatted: