Skip to main content

Source: Operating Systems: Three Easy Pieces (OSTEP) — Chapter 50, Arpaci-Dusseau & Arpaci-Dusseau

The Andrew File System (AFS)

CMU’s AFS (Satyanarayanan et al.) [H+88] aimed at scale: how many clients can one server support?

NFS burns server time on frequent cache-validity checks. AFS also wanted clear user-visible consistency: on open, you generally get a consistent latest copy — not NFS’s timeout-dependent fuzziness.

AFSv1 (ITC DFS)​

Whole-file caching on the client’s local disk (Venus client / Vice servers):

  1. open → Fetch (full pathname) → write file to local disk
  2. read / write → local FS only (may also hit client RAM cache)
  3. close → if dirty, Store whole file back
  4. Later access → TestAuth; reuse local copy if unchanged

Contrasts with NFS: whole files (not blocks), disk (not only memory). v1 cached file contents; directories stayed at the server.

Quiz

Rank the sequence

1 / 1

Order the AFSv1 whole-file caching lifecycle (top = first).

OrderDrag the handle to rearrange — top should be first.

  1. 1read/write hit the local disk copy (and maybe client RAM cache)
  2. 2close, if the file is dirty, Stores the whole file back to the server
  3. 3A later access does a TestAuth and reuses the local copy if unchanged
  4. 4open triggers a Fetch of the full file to local disk

Drag items into the correct order (or use ↑↓), then check.

What measurement found​

Patterson’s Law: measure the problem before rebuilding.

ProblemEffect
Pathname walks on Fetch/StoreServer CPU spent in directory traversal
Too many TestAuthsLike NFS GETATTR storms
(+ load imbalance, per-client processes)Volumes + threads in v2

Result: ~20 clients per overloaded server.

AFSv2: callbacks + FIDs​

Crux: redesign the protocol to cut server interactions and make remaining ones cheap.

  • Callback: server promises to notify the client if a cached file/dir changes → client stops polling (interrupts vs polling)
  • FID: volume ID + file ID + uniquifier (like an NFS file handle). Client walks the path one component at a time, caches each dir/file, and registers callbacks

First open of /home/remzi/notes.txt does several Fetches; afterward, if callbacks remain valid, opens are local. Scale rose to ~50 clients/server; common-case speed near local disk.

Quiz

Rank the sequence

1 / 1

Order the AFSv2 callback-based access to /home/remzi/notes.txt (top = first).

OrderDrag the handle to rearrange — top should be first.

  1. 1The next open after the break must re-Fetch from the server, since the cached copy is no longer trusted
  2. 2The first open walks the path one component at a time, Fetching and caching each dir/file, registering a callback for each
  3. 3A later open finds the callback still valid and is served entirely from the local cache
  4. 4The server later notices the file changed and breaks the callback, notifying the client

Drag items into the correct order (or use ↑↓), then check.

Cache consistency​

ScopeRule
Different machinesUpdates visible + remote caches invalidated at close (flush + break callbacks)
Same machineImmediate visibility (UNIX-like)
Concurrent writersLast closer wins — whole file from one client, not an NFS block mix

DFS baseline consistency is for casual “log into another machine and see my files” — apps that care about concurrent updates still need locks.

Crash recovery (cost of state)​

Callbacks live in server memory. Client reboot may miss callback breaks → treat cache as suspect; TestAuth before reuse. Server reboot forgets all callbacks → clients must revalidate. Heavier than NFS’s “just retry the stateless op.”

Performance vs NFS (qualitative)​

Often similar on first fetch. AFS wins on large-file re-reads (local disk cache vs NFS re-fetch). AFS loses on overwrite (fetch then replace) and tiny I/O into huge files (always whole-file). Workload assumptions matter: AFS assumed infrequent sharing and whole-file sequential access.

Other improvements​

True global namespace, serious security, flexible ACLs, admin tools for volumes. Marketplace favored open NFS/CIFS; AFS’s lasting influence is ideas (callbacks, clearer consistency) — NFSv4 even adds more server state.

Interactive​

Try: goals · v1 limits · callbacks/FIDs · consistency · trade-offs.

Check your understanding​

Quiz

Andrew File System

1 / 6

AFS’s primary design goal emphasized in this chapter is…

Pick an answer to see if you are right.

Coding challenges​

Homework lab: afs.py​

Use the OSTEP dist-afs homework (afs.py).

Lab

Homework: afs.py

0/3 started

Loading lab…

Summary​

IdeaTakeaway
ScaleCut server chatter (callbacks, path FIDs)
Whole-file + diskCommon case ≈ local FS
ConsistencyClose visibility + last closer; simple story
CostStateful recovery; bad for tiny/partial updates
LegacyIdeas & tools; NFS/CIFS won the market

Previous: Sun’s NFS

Next: Distributed systems dialogue / wrap-up (OSTEP Ch. 51+).

Further Reading​