[krbdev.mit.edu #372] rcache speedup via removing fsync() call

[Nicolas Williams]

And what about adding rcache locking?  How does that affect the
performance? :)

On Wed, Aug 27, 2003 at 12:20:43AM -0400, Ken Raeburn via RT wrote:
> 
> > 	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 :-).
> 
> Unfortunately(?), some systems can come back up much quicker than that. 
> But maybe we can figure out some way to deal...  Tom and I kicked around
> a few ideas, but didn't get to anything beyond either doing the fsync,
> skipping the replay cache altogether because the protocol makes it
> unnecessary, or suffering with the replay vulnerability.
> 
> I did a little testing tonight, using a program that just adds to the
> replay cache as quickly as it can for about five minutes, and when I
> disabled the fsync call, the program ran faster by about a factor of
> four, and it didn't keep the Linux kjournald process busy the whole
> time.  But even with the fsync call, I was able to add around 1200
> replay cache entries per second on average.  (Starting with an empty
> cache, not running long enough to trigger an expunge, etc...not a
> perfect test by any means.)
> _______________________________________________
> krb5-bugs mailing list
> krb5-bugs at mit.edu
> http://mailman.mit.edu/mailman/listinfo/krb5-bugs