How to prevent very very large ccaches?

[Nicolas Williams]

On Tue, Jun 18, 2002 at 05:41:22PM -0400, Ken Raeburn wrote:
> Wow.  I knew we had some bogus stuff in some of our I/O code, but
> didn't realize it was so serious.

It's not too bad - the fix seems to be reasonably small... But I was
seeing a load average close approximating the number of krsh (actually,
ssh) processes running at any given time with the same large ccache.
I.e., if I had 20 sshs going then the load average shot up as hifh as 16
when the ccache got large enough.

Note my being uncomfortable with fiddling with the OPENCLOSE in
krb5_get_credentials()... I think there may be other funnyness going on
that currently doesn't bite anyone. Specifically I worry that the
OPENCLOSE() macros and the code that uses them may result in work being
done with the ccache fd is -1 (i.e., the ccache file is not open) if
said code is called with the OPENCLOSE flag unset. Ugh, let me restate
that: there seems to be, at first glance, code which expects the ccache
fd to be open if the OPENCLOSE flag is not set, but there may be no way
to make sure that this is so in krb5_get_credentials()... Again, this is
from a cursory look.

> If the ccache is passed in, I think the flag state should be restored
> at the end to the way the caller might have set it.  But I think
> cc_retr.c is the right place for temporarily overriding the one flag.

Note that there is no get_flags() function/macro for ccaches, so how can
restore the flag to the previous setting if I cannot find out what that
is? The comment in the patch states this too. The assumption seems to be
made everywhere that OPENCLOSE is normally set all times, with special
exceptions in cccopy.c and, now, I hope, cc_retr.c :)

> So is performance acceptable at 1000 entries now, or should we look at
> a db2 ccache format? :-)

I'll actually do a full test tomorrow. For now I see that truss/strace
confirms that the clients no longer open/fcntl lock/close for every
damned ccache entry, so I'm reasonably confident that the problem is
solved well enough for our needs.

Would an indexed ccache layout be better? Maybe, but I think an
IPC/daemon ccache where the daemon uses MEMORY ccaches would be even
better (and it would avoid the need to do any work with db2 or any other
db).

> Ken


Cheers,

Nico
-- 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

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.