The Andrew File System andrew file system AFS — a distributed file system developed at CMU in the 1980s (led by M. Satyanarayanan) with the overriding goal of scale: supporting as many clients per server as possible. It achieves this with whole-file caching to the client's local disk plus server callbacks, and offers a consistency model far simpler to reason about than NFS's. Its client-side code is called Venus and its servers are collectively called Vice.
defined in ch. 50 — open in glossary
(AFS, CMU, 1980s) was
built around one goal: scale — how many clients can a single server support?
Where NFS makes clients constantly poll the server to validate caches (burning
server CPU), AFS is designed to minimize server interaction. It also made
understandable consistency a first-class concern: on open(), a client
generally just gets the latest consistent copy.
50.1 AFS Version 1
The defining idea, present in every AFS version, is whole-file caching whole-file caching AFS's defining technique: on open() the entire file is fetched from the server and stored on the client's local disk; all subsequent read() and write() calls are serviced purely locally with no network traffic; on close(), if the file was modified, the whole file is flushed back to the server. It contrasts with NFS, which caches individual blocks in client memory. defined in ch. 50 — open in glossary on the client’s local disk:
1open(): Fetch the whole file
The AFS client (Venus) sends a Fetch to the server (Vice), which ships the ENTIRE file back. Venus writes it to the client's local disk cache.
The client-side code is called Venus; the servers are collectively Vice. Note the sharp contrast with NFS:
| NFS | AFS | |
|---|---|---|
| caches what | individual blocks | whole files |
| caches where | client memory | client local disk (+ memory) |
| read/write cost | may hit the server on a block miss | purely local after the initial fetch |
| on close | flush dirty blocks (flush-on-close) | flush the whole file if modified (Store) |
| server trips | many small ones | a few big ones (fetch/store whole files) |
The AFSv1 protocol is small (directories were kept only at the server in this version):
| what it does | |
|---|---|
| Fetch | fetch the contents of a file (given its whole pathname) |
| Store | store this file on the server |
| TestAuth | test whether a file has changed (used to validate cached entries) |
| GetFileStat | get the stat info for a file |
| SetFileStat | set the stat info for a file |
| ListDir | list the contents of a directory |
Tip: Measure Then Build (Patterson’s Law)
Before building a new system to fix a problem, measure the old one and demonstrate the problem with experimental evidence. You gain proof you’re solving something real — and a ready-made way to show the new system is better.50.2 Problems with Version 1
The AFS team measured their prototype and found two protocol problems that capped scalability:
- Path-traversal cost. Because
Fetch/Storesend the whole pathname (e.g./home/remzi/notes.txt), the server must walk the directory tree from the root on every request. With many clients, the server burned most of its CPU just traversing paths. - Too many TestAuth messages. Just like NFS’s GETATTR flood, clients constantly asked “has my cached file changed?” — and most of the time it hadn’t. The server spent much of its time answering “no”.
(Two lesser problems: load imbalance across servers — fixed by introducing volumes volume In AFS, a unit of files that an administrator can relocate between servers to balance load. Volumes were introduced to fix the load-imbalance problem of the first AFS version; the volume identifier is also the first component of a file identifier (FID). defined in ch. 50 — open in glossary , movable units of files an admin can shift between servers — and per-client server processes, whose context-switching was fixed by moving to threads in v2.)
50.3 Improving the Protocol
Together these made the server CPU the bottleneck: each server could handle only about 20 clients before choking on TestAuth traffic and path traversal.
The Crux: How To Design a Scalable File Protocol
How can we redesign the protocol to minimize the number of server interactions (especially TestAuth messages) — and make the interactions that remain efficient? Fixing both is the path to a far more scalable AFS.Check yourself: AFSv1 and whole-file caching
1.What was AFS's overriding design goal, and how does it shape the protocol?
2.What is whole-file caching, AFS's core mechanism?
3.How does AFS's caching differ from NFS's?
4.Measurement revealed two protocol problems that limited AFSv1's scale. What were they?
5.AFSv1 also suffered load imbalance across servers. What mechanism fixed it?
6.The AFS designers followed 'Patterson's Law' before redesigning. What does it say?