Andrew File System
AFS vs NFS
Some definitions and general technology
The Andrew File System, AFS, was developed at the CMU and named after the first names of the founders of the university: Andrew Carnegie and Andrew Mellon.
The idea behind the design was to create a network with computers for all the students and employees of the university (up to 10000 users), aka: a major aspect was that it should be capable of scaling up easily. The maximum is about 200 clients with 1 server, but in practice it is advised to use a ratio of 50:1.
Currently AFS is marketed, maintained, and extended by Transarc Corporation (and at the moment of writing, Transarc is part of IBM.). Check their website for currently supported platforms and there's a client-only implementation "AFS Client for Windows/NT". The latest version is AFS 3.6 (search their list for most up-to-date information and white papers).
The main stuff you really need to know about:
- Venus runs on the client PCs, hence providing the interface between the client and vice.
- Vice runs on the server and is cache manager as well.
- fid = file identifier, similar to the i-node in UNIX.
- A volume is a collection of directories.
- A cell is a collection of volumes (IRL often a collection of servers grouped together administratively) and presenting a single, cohesive filesystem. Typically, an AFS cell is a set of hosts that use the same Internet domain name. So, these cells may be local on same LAN or remotely somewhere on the WAN.
- The Cache Manager maintains information about the identities of the users logged into the machine, finds and requests data on their behalf, and keeps chunks of retrieved files (64K at a time) on local disk.
The configuration is a combination of clusters, where each cluster consists of a file server and tens of PCs.
It uses the client-server implementation of file use (up/download), see also File Service. It is assumed that most users use a PC of the same cluster, i.e. a PC residing in the same area with the very same file server running vice and thus containing their data. This doesn't mean that the users aren't allowed to login on a PC outside the cluster, but it does mean that when using a PC outside their let's say "home" file server, the up- and download time of the specified file will be considerably slower.
Further, there's replication for reliability. Multiple copies of application binaries and AFS databases are replicated on multiple file servers within a cell. When accessing this information, a client will choose among the available servers. (But I'm still curious how they implement that algorithm when the user does have write rights and the file is cached locally. IIRC it's trying to maintain consistency via the callback mechanism.) Replication also reduces the load on any particular server by placing frequently accessed information on multiple servers.
The developers list the follwing as the main strengths of AFS:
back to IT stuff
|AFS 3||NFS 3|
|File servers and clients form a logical administrative unit called a cell.||File servers and clients. Each file server is managed independently.|
|Administration by collections of files called volumes.||Administration by individual files.|
|Common, global name space viewed by all machines.||Name space not always viewed consistently across machines.|
|Automatic file location tracking by system processes and Volume Location Database.||Mountpoints for tracking file's physical location set by administrators and users.|
|Stateful servers.||Nearly stateless servers.|
|Robust disk caching reduces file server and network load.||Memory caching with small buffers.|
|Server callbacks guarantee cache consistency. Open-to-close semantics. Attributes cached several hours.||Time-based cache consistency may cause inconsistencies to occur. Attributes cached 3-30 seconds.|
|Network traffic reduced by callbacks, large buffers.||Network traffic increased by limited caching.|
|Replicas spread the load among preferred servers. No replication to reduce load.||No replication to reduce load.|
|Excellent performance in wide-area configurations.||Inefficient in wide-area configurations.|
|Scaleable; maintains performance in any size installation.||Best in small- to medium-size installations.|
|Read-only replication by volume. Automatic switchover to available replica.||No standard data replication.|
|Files remain available to users during reconfiguration. File names remain the same.||Users lose access to files during reconfiguration. File moves require mountpoint changes to adjust file names.|
|Management tasks executed from any machine.||Management tasks frequently require telnet to designated machines.|
|Disk quotas based on volumes; easy for user to check status.||Disk quotas based on user ID; difficult for user to check status.|
|No system downtime with AFS Backup System.||Standard UNIX backup requires system downtime.|
|Backup clones often used for user-controlled restores.||All restores require administrator assistance.|
|Kerberos version 4 authentication.||Unencrypted user IDs, trusted users and hosts. Can be kerberized.|
|Access control lists for fine tuning directory access. UNIX mode bits for the owner.||Access control with standard UNIX mode bits on files and directories.|
|User-definable groups.||Groups defined by system administrator.|
|Mutual authentication by system processes and databases. Always uses secure RPC.||Can use secure RPC.|
References and more information
Modern Operating Systems, A.S. Tanenbaum, Ch 13.
AFS white paper
back to IT stuff