Browse Prior Art Database

AFS Housekeeping Performance Optimization

IP.com Disclosure Number: IPCOM000108539D
Original Publication Date: 1992-Jun-01
Included in the Prior Art Database: 2005-Mar-22
Document File: 2 page(s) / 78K

Publishing Venue

IBM

Related People

Lucas, JC: AUTHOR [+3]

Abstract

Disclosed is a process which optimizes the data cache subdirectory housekeeping functions of the Andrew File System (AFS) in an OS/2* environment. This enhancement to the OS/2 AFS startup procedures reduces initialization time and provides a mechanism for cleaning up the cache file subdirectory efficiently without impacting the AFS client runtime performance.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

AFS Housekeeping Performance Optimization

       Disclosed is a process which optimizes the data cache
subdirectory housekeeping functions of the Andrew File System (AFS)
in an OS/2* environment.  This enhancement to the OS/2 AFS startup
procedures reduces initialization time and provides a mechanism for
cleaning up the cache file subdirectory efficiently without impacting
the AFS client runtime performance.

      An OS/2* environment does not have the partition size
restrictions present in a UNIX** environment (i.e., unlike UNIX,
there is no mechanism in OS/2 to restrict the size a subdirectory can
grow relative to the size available in the partition of the hard
disk).  The AFS initialization of the data file cache subdirectory
was designed with the UNIX environment in mind.  Care is taken to
ensure that only properly named data cache files and other control
files are present in the subdirectory.  The data cache subdirectory
is read from top to bottom every time the AFS client is initiated.
While this subdirectory needs to be checked periodically for
extraneous files, it does not have to occur in the main path of the
client initialization.

      The entire concept of cleaning up the data cache subdirectory
is taken out of the main path initialization. This in itself provides
for a reduction in startup time.  No action is taken on the data
cache file themselves at initialization time.

      After successful client initialization, the startup thread
(i.e., the initial thread kicked off when the client DLL is started)
has nothing more to do than wait on a semaphore for termination.  The
termination notice could be a ctrl+break, ctrl+c, or an AFS
termination request.  It is here that the data cache subdirectory
cleanup is done, separate from the client thread, but while the
client is up and run...