How to prevent very very large ccaches?
Nicolas.Williams at ubsw.com
Wed Jun 19 10:00:59 EDT 2002
Indeed, all those lseek()s and read()s sure look, well,
superfluous and inefficient.
For now it's clear that the lock/unlock for each ccache entry
sequenced causes ccaches not to scale beyond a fairly small
number of entries, N.
All those unnecessary lseek()s and read()s might mean there's
another knee in ccache sequencing for a much larger N, say,
50,000. I'm very happy to say that there are many fewer than
100,000 hosts for me to look after :) so that I don't (yet)
care about any possible knee in searching such large ccaches.
For now the OPENCLOSE fix should result in an improvement of
at least an order of magnitude when doing massive, parallel
ssh/krsh to thousands of hosts.
Note to future ccache implementors: one thing I take away
from the way I use Kerberos is that ccache searches are more
common than ccache insertions, but both must be fast enough
as to not be noticeable; O(1) insertion and lookups would be
nice, but I'd settle for O(ln(N)) :)
> -----Original Message-----
> From: Ken Hornstein [mailto:kenh at cmf.nrl.navy.mil]
> Sent: Tuesday, June 18, 2002 6:41 PM
> To: kerberos at mit.edu
> Subject: Re: How to prevent very very large ccaches?
> >Wow. I knew we had some bogus stuff in some of our I/O code, but
> >didn't realize it was so serious.
> There's a bunch of stuff in there. I noticed during a system
> call trace
> once that keytabs are apparantly read in a byte at a time. I haven't
> tracked that one down yet, though (it might be fixed in newer versions
> of Kerberos, so I haven't made a big deal about it).
> Kerberos mailing list Kerberos at mit.edu
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
More information about the Kerberos