[2664] in Kerberos-V5-bugs
krb5-libs/372: Replay cache shouldn't fsync() after every item is written
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Wed Feb 12 12:25:16 1997
Resent-From: gnats@rt-11.MIT.EDU (GNATS Management)
Resent-To: krb5-unassigned@RT-11.MIT.EDU
Resent-Reply-To: krb5-bugs@MIT.EDU, jik@cam.ov.com
Date: Wed, 12 Feb 1997 12:25:13 -0500
From: "Jonathan I. Kamens" <jik@kamens.brookline.ma.us>
Reply-To: jik@cam.ov.com
To: krb5-bugs@MIT.EDU
Cc: jik@cam.ov.com
>Number: 372
>Category: krb5-libs
>Synopsis: Replay cache shouldn't fsync() after every item is written
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: krb5-unassigned
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Wed Feb 12 12:22:01 EST 1997
>Last-Modified:
>Originator: Jonathan I. Kamens
>Organization:
OpenVision Technologies, Inc.
>Release: 1.0
>Environment:
N/A
>Description:
The replay cache code calls fsync() to flush data to disk
after every entry it writes into the replay cache.
This has very little, if any, benefit, since once the data is
written, it will be flushed to disk soon enough unless the machine
crashes, and if the machine crashes, it could just as easily crash
before the fsync(). And besides, it'll probably take more than five
minutes to come back up, this making the replay cache irrelevant :-).
It does, however, have a significant downside -- it makes
persistent applications run slower (without the fsync, a GSS-API
context initiation takes 10ms less) and thrashes the disk
unnecessarily when an application is receiving frequent Kerberos
requests.
In short, I think the fsync() isn't necessary and should be
removed.
>How-To-Repeat:
>Fix:
--- krb5-1.0/src/lib/krb5/rcache/rc_dfl.c Mon Nov 18 19:36:57 1996
+++ krb5-1.0/src/lib/krb5/rcache/rc_dfl.c Wed Feb 12 09:37:11 1997
@@ -523,13 +523,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:
>Unformatted:
