 |  |
7.6. NFS futures
7.6.1. NFS Version 4
In 1998, Sun Microsystems and the Internet Society completed an agreement giving the Internet Society control over future versions of NFS, starting with NFS Version 4. The Internet Society is the umbrella body for the Internet Engineering Task Force (IETF). IETF now has a working group chartered to define NFS Version 4. The goals of the working group include:- Better access and performance on the Internet
- NFS can be used on the Internet, but it isn't designed to work through firewalls (although, in Chapter 12, "Network Security" we'll discuss a way to use NFS through a firewall). Even if a firewall isn't in the way, certain aspects of NFS, such as pathname parsing, can be expensive on high-latency links. For example, if you want to look at /a/b/c/d/e on a server, your NFS Version 2 or 3 client will need to make five lookup requests before it can start reading the file. This is hardly noticeable on an ethernet, but very annoying on a modem link.
- Mandatory security
- Most NFS implementations have a default form of authentication that relies on a trust between the client and server. With more people on the Internet, trust is insufficient. While there are security flavors for NFS that require strong authentication based on cryptography, these flavors aren't universally implemented. To claim conformance to NFS Version 4, implementations will have to offer a common set of security flavors.
- Better heterogeneity
- NFS has been implemented on a wide array of platforms, including Unix, PCs, Macintoshes, Java, MVS, and web browsers, but many aspects of it are very Unix-centric, which prevents it from being the file-sharing system of choice for non-Unix systems. For example, the set of attributes that NFS Versions 2 and 3 use is derived completely from Unix without thought about useful attributes that Windows 98, for example, might need. The other side of the problem is that some existing NFS attributes are hard to implement by some non-Unix systems.
- Internationalization and localization
- This refers to pathname strings and not the contents of files. Technically, filenames in NFS Versions 2 and 3 can only be 7-bit ASCII, which is very limiting. Even if one uses the eighth bit, that still doesn't help the Asian users. There are no plans to add explicit internationalization and localization hooks to file content. The NFS protocol's model has always been to treat the content of files as an opaque stream of bytes that the application must interpret, and Version 4 will not vary from that. There has been talk of adding an optional attribute that describes the MIME type of contents of the file.
- Extensibility
- After NFS Version 2 was released, it took nine years for the first NFS Version 3 implementations to appear on the market. It will take at least seven years from the time NFS Version 3 was first available for Version 4 implementations to be marketed. The gap between Version 2 and Version 3 was especially painful because of the write performance issue. Had NFS Version 2 included a method for adding procedures, the pain could have been reduced.
- No sideband protocols
- The separate protocols for mounting and locking have been incorporated into the NFS protocol.
- Statefulness
- NFS Version 4 has an OPEN operation that tells the server the client has opened the file, and a corresponding CLOSE operation. Recall earlier in this chapter, in Section 7.2.2, "Statelessness and crash recovery" that the point was made that crash recovery in NFS Versions 2 and 3 is simple because the server retains very little state. By adding such state, recovery is more complicated. When a server crashes, clients have a grace period to reestablish the OPEN state. When a client crashes, because the OPEN state is leased (i.e., has a time limit that expires if not renewed), a dead client will eventually have its leases timed out, allowing the server to delete any state. Another point in Section 7.2.2, "Statelessness and crash recovery" is that the operations in NFS Versions 2 and 3 are nonidempotent where possible, and the idempotent operations results are cached in a duplicate request cache. For the most part, this is still the case with NFS Version 4. The only exceptions are the OPEN, CLOSE, and locking operations. Operations like RENAME continue to rely on the duplicate request cache, a solution with theoretical holes, but in practice has proven to be quite sufficient. Thus NFS Version 4 retains much of the character of NFS Versions 2 and 3.
- Aggressive caching
- Because there is an OPEN operation, the client can be much more lazy about writing data to the server. Indeed, for temporary files, the server may never see any data written before the client closes and removes the file.
