Citation: J.H. Howard, M.L. Kazar, S.G. Menees, D.A. Nichols, M. Satyanarayanan, R.N. Sidebotham, and M.J. West, "Scale and Performance in a Distributed File System", ACM Transactions on Computer Systems, February 1988, pp. 51-81. * Summary The Andrew File System is described, and the mechanisms used to enable it to scale to large numbers of computers is discussed. * Andrew File System AFS is composed of a number of trusted servers, collectively known as Vice, and a user-level process on each client known as Venus, which caches files from Vice and stores modified copies back on the servers they came from. AFS provides a homogenous, location-transparent file name space to all clients. Venus only communicates with Vice when a file is opened or closed, as all reading/writing of data is performed directly on the cached file and bypass Venus. This client-centric design is motivated by the desire to support as many clients as possible per Vice server. Only functions essential to the integrity, availability, or security of the file system are performed by Vice. * Andrew Benchmark A synthetic benchmark was constructed to be a representative sample of the kinds of actions an average user might perform. The benchmark consists of five phases, and has a read-only source tree as input: (1) MakeDir - makes a target subtree identical in structure to the source subtree, (2) Copy - copies every file from the source subtree to the target, (3) ScanDir - recursively traverses the target subtree and examines the status of every file, (4) ReadAll - scans every byte of every file in the target subtree, (5) Make - compiles and links all the files in the subtree * Prototype System The prototype system had the following qualities: 1) the server maintained a process per client, and communication and data sharing between processes was done using files 2) clients requested files using full pathnames 3) Venus considered cached files suspect, and checked the timestamp with Vice before using them Which had the following bad performance: 1) 90% of calls to TestAuth (60%) and GetFileStat(30%) 2) CPU load on the server was high due to context switching and pathname lookups 3) there was load imbalance across the servers, due to some files being more popular than others * The Second System Armed with the faults of the first system, the second system was designed with a goal of 50 users/server. Client caching was redesigned so that files, directories, and links were cached on disk, while status information was cached in virtual memory for rapid servicing of stat calls. Modifications to directories are performed directly on the owning Vice server, and reflected in the Venus cache. To eliminate file status calls to the server, clients assume no file modifications unless notified. This requires the use of a stateful server to maintain a list of clients for each cached file, and to issue callbacks whenever a client decides to write the file. The system switched to a unique file identifier rather than a pathname, and clients were responsible for translating pathnames to fids. The fid is composed of three parts: a volume number, a vnode number, and a uniquifier. Servers now maintain a volume location database, and the server who has the file uses the vnode number as an index to obtain the file inode. Clients also cache volume location information. Vice servers now used only a single process, with five LWPs. A LWP is bound to a client only for the duration of a single server operation. Venus also uses LWPs in order to support concurrent file access requests from users. A volume is a collection of files formin a partial subtree fo the Vice name space. Mount points are leaf nodes of a volume that specify the name of another volume whose root is attached at that node. Volumes reside entirely within a single disk partition. Volumes provide units of manageability that may be placed among the Vice servers for balanced utilization. Movement of volumes between servers is considered an atomic operation, and is performed by creating a frozen copy-on-write snapshot of the volume, constructing a machine independent version of the snapshot, shipping it to the new site, and regenerating the volume at the remote site. If any changes occur to the original volume while the move is occuring, those files changed are sent to the new site using an incremental clone. Once the new volume is updated, it is made available to clients and the previous volume is disabled.