Chapter 5: Future AFS Design Re?nements

Section 5.1: Overview

The current AFS WADFS design and implementation provides a high-performance, scalable, secure, and flexible computing environment. However, there is room for improvement on a variety of fronts. This chapter considers a set of topics, examining the shortcomings of the current AFS system and considering how additional functionality may be fruitfully constructed.
Many of these areas are already being addressed in the next-generation AFS system which is being built as part of Open Software Foundation?s (OSF) Distributed Computing Environment [7] [8].

Section 5.2: unix Semantics

Any distributed file system which extends the unix file system model to include remote file accesses presents its application programs with failure modes which do not exist in a single-machine unix implementation. This semantic difference is dificult to mask.
The current AFS design varies from pure unix semantics in other ways. In a single-machine unix environment, modifications made to an open file are immediately visible to other processes with open file descriptors to the same file. AFS does not reproduce this behavior when programs on different machines access the same file. Changes made to one cached copy of the file are not made immediately visible to other cached copies. The changes are only made visible to other access sites when a modified version of a file is stored back to the server providing its primary disk storage. Thus, one client's changes may be entirely overwritten by another client's modifications. The situation is further complicated by the possibility that dirty file chunks may be flushed out to the File Server before the file is closed.
The version of AFS created for the OSF offering extends the current, untyped callback notion to a set of multiple, independent synchronization guarantees. These synchronization tokens allow functionality not offered by AFS-3, including byte-range mandatory locking, exclusive file opens, and read and write privileges over portions of a file.

Section 5.3: Improved Name Space Management

Discovery of new AFS cells and their integration into each existing cell's name space is a completely manual operation in the current system. As the rate of new cell creations increases, the load imposed on system administrators also increases. Also, representing each cell's file space entry as a mount point object in the /afs directory leads to a potential problem. As the number of entries in the /afs directory increase, search time through the directory also grows.
One improvement to this situation is to implement the top-level /afs directory through a Domain-style database. The database would map cell names to the set of server machines providing authentication and volume location services for that cell. The Cache Manager would query the cell database in the course of pathname resolution, and cache its lookup results.
In this database-style environment, adding a new cell entry under /afs is accomplished by creating the appropriate database entry. The new cell information is then immediately accessible to all AFS clients.

Section 5.4: Read/Write Replication

The AFS-3 servers and databases are currently equipped to handle read/only replication exclusively. However, other distributed file systems have demonstrated the feasibility of providing full read/write replication of data in environments very similar to AFS [11]. Such systems can serve as models for the set of required changes.

Section 5.5: Disconnected Operation

Several facilities are provided by AFS so that server failures and network partitions may be completely or partially masked. However, AFS does not provide for completely disconnected operation of file system clients. Disconnected operation is a mode in which a client continues to access critical data during accidental or intentional inability to access the shared file repository. After some period of autonomous operation on the set of cached files, the client reconnects with the repository and resynchronizes the contents of its cache with the shared store.
Studies of related systems provide evidence that such disconnected operation is feasible [11] [12]. Such a capability may be explored for AFS.

Section 5.6: Multiprocessor Support

The LWP lightweight thread package used by all AFS system processes assumes that individual threads may execute non-preemeptively, and that all other threads are quiescent until control is explicitly relinquished from within the currently active thread. These assumptions conspire to prevent AFS from operating correctly on a multiprocessor platform.
A solution to this restriction is to restructure the AFS code organization so that the proper locking is performed. Thus, critical sections which were previously only implicitly defined are explicitly specified.