Our database of approximately 50,000 ka entries takes about
9996352 bytes, so that would make for a complete database of
about 20 megabytes for 100,000 entries. You should probably
have additional free space of at least another 20 megabytes for
error recovery purposes.
Depending on how the ka database is organized internally,
the configuration of the machine, your network configuration
and your use of kerberos, this may or may not be adequate.
Chances are that it will be, but this is stretching things
a bit. If your users like to reset their passwords frequently,
the machines are slow and unreliable, and the network connection
bad, you may not like the results. If your users hate to change their
passwords, the network connection is fast, and the machines are well
endowed, you should not have any problems. The issue here
is that ubik has problems with frequent writes to large
databases -- this would be a mild case of the "backup database blues"
people are starting to complain about. Ubik also has problems
with resyncing a large database - it does many more database copies
than it really needs to, which greatly slows down restarts.
Ubik is also quite fond of "fsync"--on a 20M file, that means
any database write activity is going to produce an inevitable performance
hit.
My guess is, assuming nice fast modern machines and networks, & typical
users, this will work, but will be pushing things "just a bit".
Another fascinating issue:
if these are full fledged AFS users, ie, pt entries as well,
you will definitely exceed the 15 bit UID limit of many operating
systems. This will definitely make your life interesting.
-Marcus Watts
UM ITD RS Umich Systems Group
