Search

As data volumes to be processed in all domains; scientific, professional, social…etc., are increasing at a high speed, their management and storage raises more and more challenges. The emergence of highly scalable infrastructures has contributed to the evolution of storage management technologies. However, numerous problems have emerged such as consistency and availability of data, scalability of environments or yet the competitive access to data. The objective of this paper is to review, discuss and compare the main characteristics of some major technological orientations existing on the market, such as Google File System (GFS) and IBM General Parallel File System (GPFS) or yet on the open source systems such as Hadoop Distributed File System (HDFS), Blobseer and Andrew File System (AFS), in order to understand the needs and constraints that led to these orientations. For each case, we will discuss a set of major problems of big data storage management, and how they were addressed in order to provide the best storage services.

This letter presents the design and implementation of a video streaming file server system, which has been implemented in the context of a distributed digital multimedia broadcasting environment that has been prototyped. To make a performance analysis of file systems and distributed object services for continuous media (CM) provisioning, we validate the performance of the system against that of a conventional file system, Unix file system, through an experimental evaluation.

The CSFS (cryptographic storage file system) is a network file storage system that is suitable for a small-to-medium sized networks such as a campus network. In a CSFS, a lot of distributed file servers are organized in a star-liked architecture. File names are stored in a name server and file data are stored in distributed file servers. A CSFS has good scalability and is able to accommodate hundreds of file servers. We implemented a CSFS in pure Java and tested the system with a benchmark. The test results show that CSFS delivers acceptable performance for general file operations. Its performance of file upload and download is as efficient as FTP. It can support more than 450 concurrent online users. Copyright © 2005 John Wiley & Sons, Ltd.

Frascati Tokamak Upgrade (FTU) data management system underwent several developments in the last year, mainly due to the availability of huge amount of open source software and cheap commodity hardware. First of all, we replaced the old and expensive four SUN/SOLARIS servers running AFS (Andrew File System) fusione.it cell with three SuperServer Supermicro SC-742. Secondly Linux 2.4 OS has been installed on our new cell servers and OpenAFS 1.2.8 open source distributed file system has replaced the commercial IBM/Transarc AFS. A pioneering solution—SGI’s XFS file system for Linux—has been adopted to format one terabyte of FTU storage system on which the AFS volumes are based. Benchmark tests have shown the good performances of XFS compared to the classical ext3 Linux file system. Third, the data access software has been ported to Linux, together with the interfaces to Matlab and IDL, as well as the locally developed data display utility, SHOX. Finally a new Object-Oriented Data Model (OODM) has been developed for FTU shots data to build and maintain a FTU data warehouse (DW). FTU OODM has been developed using ROOT, an object oriented data analysis framework well-known in high energy physics. Since large volumes of data are involved, a parallel data extraction process, developed in the ROOT framework, has been implemented taking advantage of the AFS distributed environment of FTU computing system.

The growth of data warehouse in tokamak experiment is leading fusion laboratories to provide new IT solutions in data handling. In the last three years, the Frascati Tokamak Upgrade (FTU) experimental database was migrated from IBM-mainframe to Unix distributed computing environment. The migration efforts have taken into account the following items: (1) a new data storage solution based on storage area network over fibre channel; (2) andrew file system (AFS) for wide area network file sharing; (3) ‘one measure/one file’ philosophy replacing ‘one shot/one file’ to provide a faster read/write data access; (4) more powerful services, such as AFS, corba and MDSplus to allow users to access FTU database from different clients, regardless their O.S.; (5) large availability of data analysis tools, from the locally developed utility show to the multi-platform Matlab, interactive data language and jScope (all these tools are now able to access also the Joint European Torus data, in the framework of the remote data access activity); (6) a batch-computing cluster of Alpha/CompaqTru64 CPU based on CODINE/GRD to optimize utilization of software and hardware resources.

Distributed storage systems have greatly evolveddue to cloud computing upsurge in the past several years. Thedistributed file systems inherit many components fromcentralized ones and use them in a distributed manner. There aretwo ways to grow the storage capacity: by scaling-up or byscaling-out and growing the number of storage devices in astorage system. The growth of storage devices impose manychallenges related to interconnection protocols and topologies,error handling, data consistency, security and so on. In thisarticle we have studied how distributed and parallel storageshave evolved from direct connected storages in terms ofarchitecture, data management and organization and how thenew challenges imposed by data distribution have been solved.We have selected for studying several of the most representativedistributed storages solutions: Andrew File System, Google FileSystem, General Parallel File System, Lustre and Ceph. First, weemphasize how a generic distributed storage layout has inspiredfrom structured disk layout (Berkeley Fast File System). Second,we describe the evolution path of distributed storages from awide variety of perspectives, including: distributed units whichare moving from blocks to objects due to their undeniableadvantages or distribution methods that have evolved from listsmuch like inode mapping to deterministic hash functions likeRUSH or CRUSH. Third, the networks are evolving very fast interms of topologies and protocols. Using graph theory,researchers are continuously improving different aspects ofcluster networks. Fourth, storage security is a critical componentdue to the demand of storing sensitive data for long term, sharingit in a secure way and impacting as little as possible the systemperformance.

A file system is used for the organization, storage, retrieval, naming, sharing, and protection of files. Distributed file system has certain degrees of transparency to the user and the system such as access transparency, [2] location transparency, failure transparency, heterogeneity, replication transparency etc. [1][2] NFS (Network File System), RFS (Remote File Sharing), Andrew File System (AFS) are examples of Distributed file system. Distributed file systems are generally used for cloud computing applications based on [4] the MapReduce programming model. A MapReduce program consist of a Map () procedure that performs filtering and a Reduce () procedure that performs a summary operation. However, in a cloud computing environment, sometimes failure is occurs and nodes may be upgraded, replaced, and added in the system. Therefore load imbalanced problem arises. To solve this problem, load rebalancing algorithm is implemented in this paper so that central node should not overloaded. The implementation is done in hadoop distributed file system. As apache hadoop is used, security issues are arises. To solve these security issues and to increase security, [17]Kerberos authentication protocol is implemented to handle multiple nodes. This paper shows real time implementation experiment on cluster.

ASDEX Upgrade today delivers approximately 25 GBytes of data per week. To manage this demand, which in fact is a growth by a factor of two in the last 2 years, several improvements to the data acquisition (DAQ) system have been made to avoid bottlenecks and to enhance the usability. Modifications were done to the diagnostic clients to speed up the storage of big diagnostic files to the central analysis server. The diagnostic synchronization server has been modified to handle wait requests not only for raw but for any level of evaluated data files. The central analysis server has been upgraded to deliver the power to do synoptic data analysis on up to 500 MBytes/shot on a single multiprocessor machine in shared memory. Additionally a cluster of ten workstations for parallel applications has been built up for MHD equilibrium calculations and other CPU-intensive tasks. The Andrew File System (AFS) archive servers have been upgraded to more disk capacity, a redundant storage architecture and faster network connections. However, as a basis for these improvements the network backbone and the server connections have been moved from FDDI to Gigabit-Ethernet and single workstation connections from Ethernet to Fast-Ethernet. Performance analysis results give an impression of the achieved improvements. Other projects in conjunction with the DAQ system at ASDEX Upgrade are the ‘hotlink’ interface system development for the Soft-X-Ray and Mirnov-Probes diagnostics and the ‘S-link’ development for an enhanced electron cyclotron emission (ECE) diagnostic. Both will serve as prototypes for future real-time diagnostics, which shall be able to deliver processed data in real-time to other systems — especially experiment control — to achieve a possibly better experiment performance.

The next generation of fusion experiments will use object-oriented technology creating the need for world wide sharing of an underlying hierarchical file-system. The Andrew file system (AFS) is a well known and widely spread global distributed file-system. Multiple-resident-AFS (MR-AFS) combines the features of AFS with hierarchical storage management systems. Files in MR-AFS therefore may be migrated on secondary storage, such as roboted tape libraries. MR-AFS is in use at IPP for the current experiments and data originating from super-computer applications. Experiences and scalability issues are discussed.

This paper describes a modular, graphical, fully implemented CAD tool for building timers to model computer pipelines. The complete system is composed of three parts which can exist independently but have been fully integrated to provide a user-friendly CAD tool. These parts are, first, modular nets (MNETS), a new modeling concept for modular, graphical implementation of pipeline structures of any kind; second, the implementation of various MNETS modules and macros in a VHDL library similar to logic and circuit design libraries; and third, the integration of parts 1 and 2 into an existing graphical entry framework, the EDA Wizard graphical editor. A graphical model is constructed by interconnecting basic building blocks using the graphical tool, similarly to the way circuits and logic are designed. Selection of a menu option will produce a VHDL description of this graphical model, which can subsequently be simulated on a VHDL simulator. This paper concentrates on part 1, the features of MNETS which make it inherently modular and consequently graphical. The two crucial requirements, namely the construct for storing of state and a control mechanism for the passing of state, are unique to MNETS and are discussed in detail, with comparisons to other methodologies. A brief discussion of some features and macros available in the existing MNETS library is included, as well as one simple modeling example. This library can be accessed on the IBM Andrew file system, AFS. A detailed MNETS user/design manual is available which describes MNETS in detail, as well as the library, memory hierarchy design, and modeling.

Computational Tree Logic (CTL) model update is an approach to software verification and modification, where minimal change is employed to generate updated models that represent the corrected software design. In this paper, we propose a new update principle named minimal change with maximal reachable states (II) which is a further optimisation of an existing algorithm to solve a model explosion problem during CTL model update. We provide comparison of the two methods based on Graph Theory. The algorithm of this update principle is also provided. Our experimental results show that in the case of updating the Andrew File System protocol model, the new CTL update approach significantly narrows down the committed models to fewer strong committed models.

The EPSRC pilot project Meeting the Design Challenges of nanoCMOS Electronics (nanoCMOS) is focused upon delivering a production level e-Infrastructure to meet the challenges facing the semiconductor industry in dealing with the next generation of 'atomic-scale' transistor devices. This scale means that previous assumptions on the uniformity of transistor devices in electronics circuit and systems design are no longer valid, and the industry as a whole must deal with variability throughout the design process. Infrastructures to tackle this problem must provide seamless access to very large HPC resources for computationally expensive simulation of statistic ensembles of microscopically varying physical devices, and manage the many hundreds of thousands of files and meta-data associated with these simulations. A key challenge in undertaking this is in protecting the intellectual property associated with the data, simulations and design process as a whole. In this paper we present the nanoCMOS infrastructure and outline an evaluation undertaken on the Storage Resource Broker (SRB) and the Andrew File System (AFS) considering in particular the extent that they meet the performance and security requirements of the nanoCMOS domain. We also describe how metadata management is supported and linked to simulations and results in a scalable and secure manner.

Most error-log analysis studies perform a statistical fit to the data assuming a single underlying error process. The authors present the results of an analysis that demonstrates that the log is composed of at least two error processes: transient and intermittent. The mixing of data from multiple processes requires many more events to verify a hypotheses using traditional statistical analysis. Based on the shape of the interarrival time function of the intermittent errors observed from actual error logs, a failure-prediction heuristic, the dispersion frame technique (DFT), is developed. The DFT was implemented in a distributed system for the campus-wide Andrew file system at Carnegie Mellon University. Data collected from 13 file servers over a 22-month period were analyzed using both the DFT and conventional statistical methods. It is shown that the DFT can extract intermittent errors from the error log and uses only one fifth of the error-log entry points required by statistical methods for failure prediction. The DFT achieved a 93.7% success rate in predicting failures in both electromechanical and electronic devices. >

AFS is a secure distributed global file system providing location independence, scalability and transparent migration capabilities for data. AFS works across a multitude of Unix and non-Unix operating systems and is used at many large sites in production for many years. AFS still provides unique features that are not available with other distributed file systems even though AFS is almost 20 years old. This age might make it less appealing to some but with IBM making AFS available as open-source in 2000, new interest in use and development was sparked. When talking about AFS, people often mention other file systems as potential alternatives. Coda (http://www.coda.cs.cmu.edu/) with its disconnected mode will always be a research project and never have production quality. Intermezzo (http://www.inter-mezzo.org/) is now in the Linux kernel but not available for any other operating systems. NFSv4 (http://www.nfsv4.org/) which picked up many ideas from AFS and Coda is not mature enough yet to be used in serious production mode. This article presents the rich features of AFS and invites readers to play with it.

Secure management of file systems of large organizations can present significant challenges to system administrators, in terms of the number of users, shared access to parts of the file system for supporting large software projects, and securing and monitoring critical parts of the file system from intruders. We present interactive visualization tools for monitoring and viewing the complex access control relationships within large file systems. This tool is targeted as an aid to system administrators to manage users, software applications and shared access. We tested our tool on UNC Charlotte's Andrew File System (AFS), which contains 7043 users, 560 user groups, and about 2.1 million directories. Our system displays summary information about the file system, and two types of visualizations to explore access control relationships among classes of users. In addition, drill-down features are provided to explore the user file system structure and manage access control information of any directory within the system. All of the views are linked to permit easy navigation and features are provided that make the system scalable to larger filesystems.

While replication of administrative databases is important, quite often lazy propagation of updates does not suffice. This argument is couched in terms of experience with the Andrew file system (AFS) but the author believes that it generalizes to many environments. He discusses in some detail a replication library his group built, on top of which they built all of the AFS administrative servers. This library, named Ubik, is interesting for three reasons. First, it has a very simple programming interface, making it relatively easy to understand. Second, the library is quite easy to implement, while still being useful for a large class of server applications. Finally, the library uses an interesting nonblocking (in the database sense) commit protocol, providing good write as well as read availability. The author outlines Ubik's goals, gives an overview of it, and describes its quorum completion algorithm in some detail. >

The Pittsburgh Supercomputing Center (PSC) has been using the Andrew File System (AFS) to integrate its supercomputing environment. Work has been completed to make AFS the PSC's primary, permanent file-storage system. The PSC is using many of the components of this system in production. The PSC has extended AFS to meet its mass storage needs. These extensions include adding archival services to the AFS server and porting the AFS client to the Unicos operating system. The authors discuss the advantages of this system as well as how it performs in a supercomputing environment. >

The National Storage Laboratory (NSL) at the National Energy Research Supercomputer Center (NERSC) is a prototype facility which is developing data storage and retrieval techniques using hardware that includes a hierarchy of storage devices. The ultimate goal is to store terabytes of data and achieve rapid retrieval times compatible with the type of media where the data is stored. Files stored in the NSL are accessed directly using the Network File System (NFS); in the future, the Andrew File System (AFS) is expected to be used. System level control of files is available using the File Transfer Protocol (FTP) or a set of program-callable routines. We have experimented with storing and retrieving data from fusion experiments at LLNL and at General Atomics in San Diego, California, using computers running UNIX and VMS operating systems. We discuss some issues associated with accessing files whose names are known, but which are not immediately available, the time required for retrieval, and other pertinent parameters.

The authors describe current and anticipated work at the Center for Information Technology Integration at the University of Michigan in developing and integrating mass storage with distributed file systems, specifically with the Andrew File System (AFS). They present a specific approach to integrating AFS with mass storage: they consider the mass store itself to be the file system, not a bag on the side of a disk-based file system. Instead of developing a back-end server to manage the movement of data files between traditional disk-based storage systems (used, in the present case, by AFS) and magnetic-tape or optical-based mass storage systems (of which AFS has little or no knowledge), the authors envision the mass store as a first-class data repository. A traditional disk-based file system serves as a very large cache of the mass store system. On top of that is another, large, high-speed memory cache. All storage other than the mass store is used exclusively for caching. In this approach, cache management policies are of fundamental importance. >

Currently, there is a move away from huge, monolithic mainframe computers to smaller, individual workstations. This move requires that data and programs be shared between individual users on the same computer as well as across machines on a local area network (LAN) or even on a wide area network (WAN). A popular distributed file system is Transarc's Andrew File System (AFS), the precursor of the Open Software Foundation's (OSF) Distributed File Service (DFS), part of OSF's Distributed Computing Environment. This paper compares AFS and DFS with other successful distributed file systems, discussing clients and file servers, data cache (cache consistency and authentication), file system topology, access rights, privileged programs, critical data, and authentication in long-running batch jobs. >

The benefits of integrating distributed file systems with mass storage systems are presented. Key integration issues are discussed. Examples of efforts to integrate the Network File System (NFS) and the Andrew File System (AFS) with a number of mass storage systems are presented. Future research and development issues are discussed. >

The AFS (Andrew File System) with extensions forms the basis of the distributed mass storage system being implemented at the Pittsburgh Supercomputing Center (PSC). AFS offers transparent, locally cached, secure access to a universal file name space from a wide variety of UNIX platforms. The PSC is extending the standard AFS offering to provide a number of features that are useful in a supercomputing environment. The extensions include a port of AFS client code to Unicos and modifications to support high-performance disk arrays and archival servers such as the Common File System, UniTree, and robotic NSF systems. These features are implemented by the development of generalized multiple residency extensions for AFS servers. Data migration strategies are being developed. The PSC extensions require no changes to the user's AFS client code. >

The Institutional File System (IFS) project is a joint project of the Center for Information Technology Integration at the University of Michigan and the IBM Corporation. The goal of the IFS project is to offer network file services that are institution-wide, transparent, reliable, and secure. The mechanisms used to control access to system services on the IFS project are described. A logical overview of access control at the IFS project is given and is followed by an enumeration of the services on which the project relies, their interdependencies, and the mechanisms by which access to these services is secured. Present vulnerabilities and future plans are described. >

During the last two years, the experimental database of Frascati Tokamak Upgrade (FTU) has been changed from several points of view, particularly: (i) the data and the analysis codes have been moved from the IBM main frame to Unix platforms making enabling the users to take advantage of the large quantities of commercial and free software available under Unix (Matlab, IDL, …); (ii) AFS (Andrew File System) has been chosen as the distributed file system making the data available on all the nodes and distributing the workload; (iii) ‘One measure/one file’ philosophy (vs. the previous ‘one pulse/one file’) has been adopted increasing the number of files into the database but, at the same time, allowing the most important data to be available just after the plasma discharge. The client–server architecture has been tested using the signal viewer client jScope. Moreover, an object oriented data model (OODM) of FTU experimental data has been tried: a generalized model in tokamak experimental data has been developed with typical concepts such as abstraction, encapsulation, inheritance, and polymorphism. The model has been integrated with data coming from different databases, building an Object Warehouse to extract, with data mining techniques, meaningful trends and patterns from huge amounts of data.

Two small experiments at Fermilab are using the large UNIX central computing facility at Fermilab (FNALU) to analyze data. The data acquisition systems are based on {open_quotes}off the shelf{close_quotes} software packages utilizing VAX/VMS computers and CAMAC readout. As the disk available on FNALU approaches the sizes of the raw data sets taken by the experiments (50 Gbytes) we have used the Andrew File System (AFS) to serve the data to experimenters for analysis.

Discusses a client-side-only approach to providing disconnected access to a heterogeneous set of network file services. Our method contrasts with those used in systems such as Coda, primarily because Coda depends upon changes to both the client software and the server software. Instead, we assume that we cannot make changes to the servers, and we explore the resultant benefits and limitations, as manifested in our prototype implementation. Unlike the LITTLE WORK approach to disconnected operation for the Andrew File System (AFS), we do not commit to a specific file access protocol; rather, we support access to multiple file services. We describe how a usability study affected our user model, system design and implementation.

The DOMAIN system is mainly a distributed file system where an object-oriented approach is taken. It is a commercial product of Apollo Computers, Inc., that connects personal workstations and server computers. All processors transparently share a common network-wide virtual memory system that allows groups of users to share programs, files and peripherals.

The Carnegie Mellon University Library Information System (LIS), introduced in March 1986, is one of the most popular services the university libraries have offered. Distributed access to online library catalogs and other computer‐based information resources is no longer a novel approach to library services. However, Carnegie Mellon's LIS is unusual in several respects. The search interface and retrieval system, though based on IBM's STAIRS proprietary retrieval software, were custom designed by the libraries’ staff. In addition, since LIS access is not password‐controlled, anyone with access to both the campus asynchronous and TCP networks can use the system. Moreover, the Carnegie Mellon environment is particularly well suited to innovation and experimentation that goes beyond merely providing access from terminals in faculty offices or public terminal clusters. The Andrew system, an extensive campuswide network of powerful personal workstations under development by the university and IBM, is the basis for much innovation in applications of computing to teaching and research. By linking basic information resources to the Andrew campus network, the university libraries will increase the integration of information resources with routine class assignments and research.

Andrew is a distributed computing environment being developed in a joint project by Carnegie Mellon University and IBM. One of the major components of Andrew is a distributed file system which constitutes underlying mechanism for sharing information. The goals of the Andrew file system are to support growth up to at least 7000 workstations (one for each student, faculty member, and staff at Carnegie Mellon) while providing users, application programs, and system administrators with the amenities of a shared file system. A fundamental result of our concern with scale is the design decision to transfer whole files between servers and workstations rather than some smaller unit such as records or blocks, as almost all other distributed file systems do. This paper examines the consequences of this and other design decisions and features that bear on the scalability of Andrew. Large scale affects a distributed system in two ways: it degrades performance and it complicates administration and day-to-day operation. This paper addresses both concerns and shows that the mechanisms we have incorporated cope with them successfully. We start the initial prototype of the system, what we learned from it, and how we changed the system to improve performance. We compare its performance with that of a block-oriented file system, Sun Microsystems' NFS, in order to evaluate the whole file transfer strategy. We then turn to operability, and finish with issues related peripherally to scale and with the ways the present design could be enchanced.

Distributed file access is a key aspect of distributed system design. The ease and the efficiency with which files on remote machines can be accessed has a very pervasive influence on the overall success and acceptance of a distributed system. Careful design is required to achieve these goals. Techniques for efficient remote file access are therefore an area of active research.The papers in this session provide quite a diverse sampling of recent efforts in the construction and the evaluation of distributed file systems. The paper by David Cheriton and Paul Roy describes the design and the performance of a file server supporting a collection of diskless workstations connected by a local area network. A much more loosely coupled environment is described by Peter Weinberger: His paper discusses the integration of a number of independently administered UNIX† machines into a network-wide file system. Finally, Paul Leach presents an evaluation of a commercial system based on a network-wide single level store.

This paper discusses distributed file access on large networks. It uses the Andrew file system, developed jointly by Carnegie Mellon University and IBM as an illustrative example of a large, unified file system. The paper concludes with thoughts on the requirements and design of geographically distributed file systems for very large networks comprising 106 nodes or more.

This paper compares two working network-based file servers, the Xerox Distributed File System (XDFS) implemented at the Xerox Palo Alto Research Center, and the Cambridge File Server (CFS) implemented at the Cambridge University Computer Laboratory. Both servers support concurrent random access to files using atomic transactions, both are connected to local area networks, and both have been in service long enough to enable us to draw lessons from them for future file servers. We compare the servers in terms of design goals, implementation issues, performance, and their relative successes and failures, and discuss what we would do differently next time.

This paper describes a simple distributed mechanism for caching files among a networked collection of workstations. We have implemented it as part of Sprite, a new operating system being implemented at the University of California at Berkeley. A preliminary version of Sprite is currently running on Sun-2 and Sun-3 workstations, which have about 1-2 MIPS processing power and 4-16 Mbytes of main memory. The system is targeted for workstations like these and newer models likely to become available in the near future; we expect the future machines to have at least five to ten times the processing power and main memory of our current machines, as well as small degrees of multiprocessing. We hope that Sprite will be suitable for networks of up to a few hundred of these workstations. Because of economic and environmental factors, most workstations will not have local disks; instead, large fast disks will be concentrated on a few server machines. In Sprite, file information is cached in the main memories of both servers (workstations with disks), and clients (workstations wishing to access files on non-local disks). On machines with disks, the caches reduce disk-related delays and contention. On clients, the caches also reduce the communication delays that would otherwise be required to fetch blocks from servers. In addition, client caches reduce contention for the network and for the server machines. Since server CPUs appear to be the bottleneck in several existing network file systems [SATY85, LAZO86], client caching offers the possibility of greater system scalability as well as increased performance. Sprite uses the file servers as centralized control points for cache consistency. Each server guarantees cache consistency for all the files on its disks, and clients deal only with the server for a file: there are no direct client-client interactions. The Sprite algorithm depends on the fact that the server is notified whenever one of its files is opened or closed, so it can detect when concurrent write-sharing is about to occur. Sprite handles sequential write-sharing using version numbers. When a client opens a file, the server returns the current version number for the file, which the client compares to the version number associated with its cached blocks for the file. If they are different, the file must have been modified recently on some other workstation, so the client discards all of the cached blocks for the file and reloads its cache from the server when the blocks are needed. The delayed-write policy used by Sprite means that the server doesn't always have the current data for a file (the last writer need not have flushed dirty blocks back to the server when it closed the file). Servers handle this situation by keeping track of the last writer for each file; when a client other than the last writer opens the file, the server forces the last writer to write all its dirty blocks back to the server's cache. This guarantees that the server has up-to-date information for a file whenever a client needs it. The file system module and the virtual memory module each manage a separate pool of physical memory pages. Virtual memory keeps its pages in approximate LRU order through a version of the clock algorithm [NELS86]. The file system keeps its cache blocks in perfect LRU order since all block accesses are through the “read” and “write” system calls. Each system keeps a time-of-last-access for each page or block. Whenever either module needs additional memory (because of a page fault or a miss in the file cache), it compares the age of its oldest page with the age of the oldest page from the other module. If the other module has the oldest page, then it is forced to give up that page; otherwise the module recycles its own oldest page. We used a collection of benchmark programs to measure the performance of the Sprite file system. On average, client caching resulted in a speedup of about 10-40% for programs running on diskless workstations, relative to diskless workstations without client caches. With client caching enabled, diskless workstations completed the benchmarks only 0-12% more slowly than workstations with disks. Client caches reduced the server utilization from about 5-18% per active client to only about 1-9% per active client. Since normal users are rarely active, our measurements suggest that a single server should be able to support at least 50 clients. We also compared the performance of Sprite to both the Andrew file system [SATY85] and Sun's Network File System (NFS) [SAND85]. We did this by executing the Andrew file system benchmark [HOWA87] concurrently on multiple Sprite clients and comparing our results to those presented in [HOWA87] for NFS and Andrew. For a single client, Sprite is about 30% faster than NFS and about 35% faster than Andrew. As the number of concurrent clients increased, the NFS server quickly saturated. The Andrew system showed the greatest scalability: each client accounted for only about 2.4% server CPU utilization, vs. 5.4% in Sprite and over 20% in NFS.