CS 736 - Spring 2007 - Paper Discussion

SUMMARY
In "Design and Implementation of the Sun Network Filesystem" Sandberg et al. present a network file system that is designed to be reasonably fast, portable, easy-to-use, transparent to the user, architecture and OS-independent, crash-resilient, and UNIX-like.

PROBLEM
In terms of features and performance, networking file systems inevitably have to compete with local file systems that have the enormous advantage of being local. The problem is that of how to design and implement a network file system comparable to a local FS.

CONTRIBUTIONS
* Identification and justification of important design goals (crash recovery,transparent access, etc.)

* Stateless design (simplified crash recovery)

* Addressed server- and client-side concerns (necessity of "unbuffered" flushes on server, VFS and vnode interface on client)

* Separating FS interface into VFS (generic FS operations) and VNODE (generic file operations) interfaces that modularize file systems.

* Identification of "hard" design and implementation choices and restrictions that needed to be made and justification of why they were made (e.g. FS naming, locking)

* Demonstration of how NFS performance evolved and reasons for performance increases.

* Admitted that security is an issue and identified it as an important aspect of future work.

FLAWS
* It is not immediately clear to me that RPC is an ideal choice for a networking FS. Authors should have addressed pros and cons of the alternatives.

* The authors make a big deal of recovery from server crashes. Though undoubtedly noble, I wonder common server crashes would actually be (which determines how much emphasis it deserves). Of course, an NFS server crash should not unleash the forces of hell upon the earth, but perhaps occasional spectacular yet survivable crash could be tolerable, if that means improvement in another aspect of the system.

* I think pros and cons of stateful alternatives should have been discussed and maybe evaluated.

* Though admittedly not a complaint about substance of the work, I take an issue with some elements of the writing style.
At times choice of presentation seemed a bit pretentious (e.g. the use of "idempotent", unless the term is common in the FS community, seems unwarranted, if only because its literal meaning comes from a very different context).
One man's "disgusting bit of UNIX trivia" is another man's fetish.

* Since when is it OK not to label axes?

PERFORMANCE:
Relative performance (we don't need to be good, just not much worse than others), time to completion, common task performance.

Summary
This paper discusses NFS, the Sun Network Filesystem and its design and implementation.

Problem
The problem is not stated as concisely as might be best but the basic problem is that remote access to filesystems was becoming increasingly important and other existing implementations were not portable and did not provide a view of the remote files that was indistinguishable from local files to programs.

Contributions
* Design goals of machine and operating system independence, crash recovery, and trsparent access, UNIX semantics maintained on client, and reasonable performance meaning about 80% as fast as local disk.
* Remote files look the same as local files.
* NFS protocol - uses Sun RPC mechanism, defined as a set of procedures, arguments and results, and are synchronous. Additionally the protocol is stateless, meaning that each request contains "all of the information necessary to complete the call, and the server does not keep track of any past requests." This is useful because it means that crash recovery is easy in that the server does not need to do crash recovery and the client just has to keep resending its request. Additionally the protocol is designed to be transport independent.
* Solution to possible looping is to not cross mount points on remote requests.

Flaws
* Use of rpc for filesystem access seems to be an odd choice. I understand the flexibility it allowed as well as easy crash recovery, but it seems inneficient.
* Lack of any real security

Relevance
Network filesystems including NFS Are in widespread use today and continue to be an important part of the computing experience.

Summary:
This paper describes the design of the Network Filesystem (NFS) and some optimizations they made to get the performance they desired.

Problem:
The Sun guys wanted a remote file system that would provide performance on par with the network disk implementation they had, but that was as close as possible to the view local disks provide (a goal that was somewhat achieved but somewhat not).

Contributions:
* NFS! This is sort of the prototypical remote file system. It's extremely widely used; for instance, I believe my undergrad alma mater's CS department uses it (but I can't remember where I heard that).
* The ability to have diskless workstations is pretty neat
* I know the paper was on NFS, but I think they should have played up their VFS/vnode stuff more. My impression is this was also a really big contribution, because it provided a generic layer that third parties could plug new file system code into.
* This is just a presentation thing, but I liked figure 3. I thought that it was a nice way of presenting the performance contributions of different optimizations

Flaws
RPC is a curious choice to use. RPC is optimized for cases where messages are very small, and the cost of running the call is on the same order as the packet transit time. By contrast, NFS is sending data blocks -- kilobytes instead of dozens of bytes -- and has a usage model where, for instance, one read request for file X means that another read request is probably coming shortly, which means that the time to set up for a stream protocol would be small in comparison to the data transfer time. In other words, it seems like NFS is exactly the case that RPC does poorly at.

Also, NFS's security model, at least as described, is essentially non-existent, because the server trusts the client to identify itself when requesting a file. Even with the reduced threat models they had in the absence of laptops and such, I can't think of any reason someone couldn't write a user-mode program that just makes an RPC call to the server, ignoring the local NFS component, identifying itself as another user. (Actually I can think of a reason, which is that the names of the NFS servers aren't public. But they couldn't be hard to find out if you have a computer connected to the network either.) I've been under the impression for a while that through version 3 of NFS, this is still an issue, but I don't know if this is accurate.

Performance
In the presentations in the paper, the authors are concerned with the time-to-completion of their benchmarks, which is of course related to latency of requests and the throughput of the network. However, they seem explicitly disinterested in the throughput on it's own ("since many people in the UNIX community base performance estimates on raw transfer speed...").

Summary:
THe paper talks about deisng and implementation details of Sun Network File System, that is based on RPC and allows file systems from remote servers be accessed as if it is a local file system.

Problem:
The remote filesystem implementations available on Unix at the time were designed exclusively for Unix. NFS was aimed at standardizing the remote file system implementation so as to make it easier to port to different operating systems and machine architectures. Other goals of the system included transparent access to remote paths (unlike other implementations which required server::path kind of access), better crash recovery and performance comparable to local file system.

Contributions:
- Standardization of protocol. By defining data representation (using XDR), NFS made possible to have independent, inter-operable implementations on possible different operating systems to communicate with each other.
- Transparent access to remote files - Clients were pretty much shielded from the physical location of files
- Not strictly related to NFS, but use of VFS and vnode interfaces. This was one thing that made NFS as close to local file systems as possible, in terms of semantics.
- Stateless protocol to allow simpler implementation on server and clients.

Flaws:
- Since the system is based on RPC, the throughput must be limited by RTT. This is because RPC has only one request outstanding at a time, to simplify implementation.
- Though it is a file system is based on networks, encryption and/or security hasnt been considered in the paper. This may not be a problem on a local intranet, but could be one if they use it over internet.
- Concurrent access restrictions is a problem - even application level locking is tricky (network delays could allow two clients to create locks at the same time).
- There isnt much detail about the implementation. The performance measurements do not talk much about the environment (network load, topology, etc)
- Though the paper talked about OS/machine independence, the entire system is modelled on Unix - syntactically and semantically. This pretty much makes all computers run Unix (or Unix-like) file systems.

Relevance:
The paper talks about many design issues related to a file system that runs over network. Most of the flaws I could think of were not really a factor when the system was originally invented. Some of the ideas proposed/implemented in the paper (virtual file system, distributed directories (yellow pages), automatic mounting, etc) are used in pretty much all modern operating systems today.