> On Thu, 13 Jul 1995, Juan Leon wrote:
>>
>> This was meant to info-afs not afshelp.
>> * problems with my aliases *
>>
>> ------- Forwarded Message
>>
>> : Date: Thu, 13 Jul 1995 16:06:52 -0500
>> : From: "Juan Leon" <[EMAIL PROTECTED]>
>> : To: Transarc AFS Help <[EMAIL PROTECTED]>
>> : Subject: building the cache.
>> : Cc: Juan Leon <[EMAIL PROTECTED]>
>> :
>> :
>> : Does any body kown how to estimate the time
>> : taken by AFS to create the cache ?
>> :
>> : What is the relation between the cache size
>> : and the time taken to create it ?
>> :
>> : We are trying to know how long it will take
>> : to create the cache in a new AFS client
>> : machine, so the user can chose whether to
>> : wait or not for AFS to comes up.
>> :
>> : But it seems not to be a lineal
>> : relation between the number of
>> : Vfiles to create and the time taken.
>> :
>> : furthermore, at the beginning the
>> : creation of Vfiles is faster, but after
>> : a while it turns slower and slower.
>> :
>> : Do you know why ?
>> :
>> : Any information will be appreciated.
> I have heard all these before, but one of my sysadmins who has to do lots of
> new machine installs has a trick that he uses that you should try.
> set the cache size to something really small when you first bring AFS up
> say 100. then once AFS is up just do an "fs setcachesize 10000" or what
> ever big number you want. AFS will the grow the cache on demand, and you
> will no longer have to wait forever. Do not forget to edit the cachinfo file
> to show the new larger number...
> Seems that this is an inital startup bug, but the workaround has been easy.
> Randall
This workaround isn't really a workaround, it's just putting off the
inevitable- When the machine is rebooted following the cache size
change, you'll still get the long delay while the extra Vfiles are
created. When you increase the cache size, there's no getting around
it- during the next reboot you'll have to wait.
Kevin
