Case Studies: NFS and AFS EEE465 2000 Reference: CDK94 ch' 8

1
Case Studies NFS and AFSEEE465 2000Reference
CDK94 ch. 8

• Major Greg Phillips
• Royal Military College of Canada
• Electrical and Computer Engineering
• greg.phillips_at_rmc.ca
• 01-613-541-6000 ext. 6190

2
Context

• Over the last three periods we have examined one
  design for a distributed file system in some
  detail
• In this period we will briefly examine the
  designs of two widely-used distributed file
  systems Suns Network File System (NFS) and the
  Andrew File System (AFS) from Carnegie-Mellon
  University
• This will conclude our overview of distributed
  file systems.

3
Network File System (NFS)

• Introduced by Sun in 1984
• Key interfaces placed in the public domain
• Design goals
• allow file sharing for relatively small
  populations
• support for HW, OS heterogeneity
• access, location, failure, performance, migration
  transparency
• Assumptions
• reliable network
• (possibly) trustworthy clients/users

4
Andrew File System (AFS)

• Developed at Carnegie-Mellon University in
  19861989
• Design goals
• scalability (to 10,000 users)
• wide distribution (over the Internet)
• access, location, failure, performance, migration
  transparency
• Assumptions
• users normally working from a single workstation
• most files small
• most files not shared
• files are referenced in bursts
• reads are much more common than writes (10x)

5
File System Models
Client
Server
Server
/
/
/
vmunix
export
nfs
NFS
usr
Remote mount (hard or soft)
Remote mount (hard or soft)
people
users
students
staff
john
paul
george
ringo
Local
Shared
/
cmu
tmp
vmunix
AFS
bin
bin
Symbolic links
6
NFS Architecture
Server computer
Client computer
User-level client process
system calls
NFS protocol
Unix kernel
Unix kernel
Net- work
Virtual file system
Virtual file system
Unix file system
NFS server
Unix file system
NFS client
7
AFS Architecture
In AFS, the Unix kernel is modified such that
non-local file access requests are routed to the
Venus user process.
User program
Venus
Network
Unix kernel
Vice
User program
Venus
Unix kernel
Unix kernel
User program
Venus
Vice
Unix kernel
Unix kernel
8
NFS File Serving Strategy

• based on RPC over UDP
• serves blocks, 8 kB at a time
• UDP packet size extended to 9 kB so that each
  block fits in a single packet
• no indication whether or not blocks are shared
• blocks are cached on the client side, with a
  timestamp
• blocks less than 3 seconds old are assumed
  current
• older blocks are revalidated before use
• this is a source of performance problems
• implements read-ahead and write-through
• write-through is also a source of performance
  problems high throughput I/O can compensate

9
AFS File Serving Strategy

• serves whole files at a time
• assumes that most files will be small fails for
  special cases like database files, etc.
• caches whole files locally typically the most
  recent hundred or so files will be cached
• for each served file,
• server maintains a callback promise that it will
  notify clients of any changes
• clients locally check validity of cached copies
  on opening
• clients check with server following a client
  failure
• clients must renew the callback for all open
  files every T minutes (typically 10)

10
Update Semantics

• Unix
• one-copy semantics
• there is one copy of the file, and each write is
  destructive (i.e., last write wins)
• NFS
• one-copy semantics, except
• clients may have out-of-date cache entries for
  brief periods of time when files are shared
• this can lead to invalid writes at the server
• AFS
• one-copy semantics, except
• if a callback message is lost, a client will
  continue working with an out-of-date copy for at
  most T minutes

11
Failure Performance

• When an NFS server fails, everything fails
• all accesses have apparent local semantics
  (except for soft mounts)
• when a server fails, it is as though the local
  disk has become unobtainable
• since authentication files are often stored on
  NFS servers, this brings down the entire system
• When an AFS server fails, life (partly) goes on
• all locally cached files remain available
• work is still possible, though there is a higher
  chance of conflict for shared files

12
Next ClassA Name Service Model