Design and Implementation of the Sun Network File System
Sandberg, Goldberg, Kleiman, Walsh, Lyon
Usenix 1995

This paper is neat:
  NFS was very successful, and still is
  You can view much net fs research as fixing problems with NFS
  You'll use NFS in labs

Why would anyone want a network file system?
  Why not store your files on the local disk?

What's the architecture?
  Server w/ disk
  LAN
  Client hosts
  apps, system calls, RPCs

What RPCs would be generated by reading file.txt, e.g.:
  fd = open("file.txt", 0)
  read(fd, buf, 8192)
  close(fd)

What's in a file handle?
  i-number (basically a disk address)
  generation number
  file system ID

What's the point of the generation number?

Why not embed file name in file handle?

How does client know what file handle to send?
  Client got it from previous LOOKUP or CREATE
  Returned handle stored in appropriate vnode
  A file descriptor refers to a vnode

Where does the client get the very first file handle?

Why not slice the system at the system call interface?
  I.e. directly package up system calls in RPCs?
  UNIX semantics were defined in terms of files
    *not* just file names
    the files themselves have identities, i-number in the disk file system
  These refer to the same object even after a rename:
    File descriptor
    Home directory
    Cache contents
  So vnodes are there to remember file-handles

What RPCs would be generated by creating a file, e.g.:
  fd = creat("d/f", 0666);
  write(fd, "foo", 3);
  close(fd);

If a server crashes and reboots, will client requests still work?
  Will client's file handles still make sense?
  File handle == disk address of i-node.

What if the server crashes just after client sends it an RPC?

What if the server crashes just after replying to a WRITE RPC?

So what has to happen on the server during a WRITE?
  I.e. what does it do before it replies to the RPC?
  Data safe on disk.
  Inode with new block # and new length safe on disk.
  Indirect block safe on disk.
  Three writes, three seeks, 45 milliseconds.
  22 writes per second. 180 kb/sec.

How could we do better than 180 kb/sec?
  Write whole file sequentially at a few MB/sec.
  Then update inode &c at end.
  Why doesn't NFS do this?

What performance fixes did they apply?
  Read-caching of data. Why does this help? (re-reading files)
  Write-caching of data. Why does this help?
  Caching of file attributes. Why does this help? (ls -l)
  Caching of name->fh mappings. Why does this help? (cache /home/rtm prefix)

How does NFS make sure my writes are visible to future readers?
  Flush dirty file contents during close()

Would it be reasonable to use NFS in Athena?
  Security -- untrusted users with root on workstations
  Scalability -- how many clients can a server support?
    Writes &c always go through to server.
    Even for private files that will soon be deleted.
  Can you run it on a large complex network?
    How is it affected by latency? Packet loss? Bottlenecks?

*** starting to overlap with NFS / Transparency lecture

What consistency semantics does this have?
  For example, if I write() and close(),
  and you open() and read(),
  do you see my modifications?
  Not if I previously read file and am caching attributes.
  How can we fix this? GETATTR on each open()?

Examples where we might care about consistency?
  Two windows open, different clients,
    emacs -> make
    make -> run the program
  Or distributed app (cvs?) with its own locks.

Examples where we might not care about consistency?
  I just use one client workstation.
  Different users don't interact / share files.

transparency -- i.e. does NFS provide local UNIX file system semantics?
  out of space: write() error vs close() error
  delete a file when in use. why would you do this?
    if unlink() on the same client, move to .nfsXXX
    if unlink() on some other client?
  chmod -r while file is open().
    owner always can read?
  execute-only (implies read)
  re-send of rename() if packet is lost
    2nd send may fail even though operation succeeded

What prevents random people from sending NFS messages to my NFS server?
  Or from forging NFS replies to my client?