AFS
===

* What are goals of AFS
  - Scale:  Maximize #clients/server
  - What are complications of scale?
      Performance
      Administrative overhead (balancing disk space, etc.)

* Prototype version of AFS
  - Architecture:
      Venus on client
      Vice on server--forks, one process per client
        server processes communicate through file system (+lock server)
        directory tree mirrors namespace
        Benefit:  Very fault tolerant
  - Protocol:
      Files referred to by full pathname
      Opens go over the wire to ensure consistency (verify timestamp)
      "Stub" directories redirect clients to another server
  - Caching:
      File cache keeps whole files
      Attribute cache for stat calls

* Evaluation of AFS prototype
  - Cache seems effective (p.56 says 81/82 percent hit rates)
  - What to conclude about Table II?
  - What is bottleneck?  CPU
  - Why is performance not scalable in Table III?
      One process per client not scalable
      Many context switches, high VM and paging demands
      Time spend in namei
  - Hard to move users' home directories from server to server
      Moving users to less loaded servers would have helped

* Improvements to AFS
  - Cache management
      Added directory and symlink caches
      Added callbacks for invalidation
  - Name resolution
      Files named by fid rather than pathname
      What's a fid?  96 bits:  <volume#, vnode#, uniquifier>
        No explicit location information!
  - Process structure
      Use LWPs instead.  What is LWP?
        Like threads, but no preemption
  - Low-level storage represenation
      Change system call interface:  iopen (today called fhopen)

* What are callbacks
    If you have file cached (cleanly)
       server lets you know before another client's write/close succeeds
    If you have file cached dirty
       server lets you know before another client's open
  - Any drawbacks to callbacks?
      Increased state at server
      Client and server state may get out of sync
      What if server can't reach a client to invalidate state?
  - Leases (not used by AFS) fix some of these problems
      Callback only promised to client for a certain lease term
      Allows server to garbage collect state w/o network messages
      If client unreachable, can safely allow file access once lease expired

* New caching scheme
  - Directories
      Consider request component by component
      Used cached component if there is callback on directory
      Otherwise, update directory (if needed) and establish callback
  - Files
      Writes are only visible on client workstation
      On close, changes are flushed back to server
      All metadata/attribute changes are synchronous
  - Potential complications?
      Disk full/server error (will only be noticed on close)
      Access checking (what if one user of client doesn't have permission)
      Reading first byte of enormous file

* Volume mechanism
  - Allow many volumes per disk (e.g., each user's home directory)
  - Quotas established per volume
  - Read-only volumes can be replicated on multiple servers
  - Snapshots/backups performed per volume (copy-on-write snapshots)
  - Volume -> server mapping replicated on all servers
  - Moving a volume:
      Make "clone" copy on write snapshot
      Copy snapshot to new server
      Make new snapshot
      Copy changes since first copy
      Freeze volume, copy any final changes
      Change volume -> server mapping
      Old server has forwarding pointer, while volume info propagates