Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) X-RT-Original-Encoding: iso-8859-1 Content-Length: 3914 From jik@kamens.brookline.ma.us Wed Feb 12 12:21:25 1997 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id MAA10197 for ; Wed, 12 Feb 1997 12:21:25 -0500 Received: from jik.saturn.net by MIT.EDU with SMTP id AA23990; Wed, 12 Feb 97 12:21:23 EST Received: (from jik@localhost) by jik.saturn.net (8.8.4/8.8.4) id MAA23021; Wed, 12 Feb 1997 12:25:13 -0500 Message-Id: <199702121725.MAA23021@jik.saturn.net> Date: Wed, 12 Feb 1997 12:25:13 -0500 From: "Jonathan I. Kamens" Reply-To: jik@cam.ov.com To: krb5-bugs@MIT.EDU Cc: jik@cam.ov.com Subject: rcache speedup via removing fsync() call X-Send-Pr-Version: 3.99 >Number: 372 >Category: krb5-libs >Synopsis: rcache speedup via removing fsync() call >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: Mon Aug 11 15:59:00 EDT 1997 >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: From: Tom Yu To: Unassigned Problem Report Cc: krb5-bugs@MIT.EDU Subject: Re: krb5-libs/372: rcache speedup via removing fsync() call Date: Wed, 12 Feb 1997 17:12:46 -0500 `Tom Yu' made changes to this PR. *** /tmp/gnatsb0032m Wed Feb 12 17:11:24 1997 --- /tmp/gnatsc0032m Wed Feb 12 17:12:34 1997 *************** *** 11,22 **** Reply-To: jik@cam.ov.com To: krb5-bugs@MIT.EDU Cc: jik@cam.ov.com ! Subject: Replay cache shouldn't fsync() after every item is written X-Send-Pr-Version: 3.99 >Number: 372 >Category: krb5-libs ! >Synopsis: Replay cache shouldn't fsync() after every item is written >Confidential: no >Severity: non-critical >Priority: low --- 11,22 ---- Reply-To: jik@cam.ov.com To: krb5-bugs@MIT.EDU Cc: jik@cam.ov.com ! Subject: rcache speedup via removing fsync() call X-Send-Pr-Version: 3.99 >Number: 372 >Category: krb5-libs ! >Synopsis: rcache speedup via removing fsync() call >Confidential: no >Severity: non-critical >Priority: low From: "Jonathan I. Kamens" To: krb5-bugs@MIT.EDU Cc: Subject: Re: krb5-libs/372: replay cache code shouldn't fsync after every entry added to the cache Date: Mon, 11 Aug 1997 15:58:49 -0400 Has this patch been merged back into the main branch of the MIT source tree? Will it be included in the next MIT release? Thanks, jik >Unformatted: