An Overview of NSFv4

The Advantages of NFSv4.1

The Gibson and Corbett paper identified some issues with NFSv4 that were successfully addressed in NFSv4.1, and NFSv4.1 is where the focus for end-user evaluation and implementation should be.

References to features in NFSv4.0 apply equally to NFSv4.1, since it was a minor version update, unlike the changes from NFSv3 to NFSv4.

On most operating systems, the name space describes the set of available files arranged in a hierarchy. When a system acts as a server to share files, it typically exports (or “shares”) only a portion of its name space, excluding perhaps local administration and temporary directories. Consider a file server that exports the following directories:

/vol/vol0

/vol/vol1

/backup/archive

The server provides a single view of the exported file systems to the client as shown in the image above.

In NFSv4, a server’s shared name space is a single hierarchy. In the example illustrated in the image, the export list and the server hierarchy is disjoint, and not connected. When a server chooses to export a disjoint portion of its name space, the server creates a pseudo-file system (the area shown in grey) to bridge the unexported portions of the name space allowing a client to reach the export points from the single common root. A pseudo-file system is a structure containing only directories, created by the server, having a unique filesystem id (fsid) that allows a client to browse the hierarchy of exported file systems.

The flexibility of the pseudo filesystem as presented by the server can be used to limit the parts of the name space that the client can see, a powerful feature that can be used to considerable advantage.

For example, to contrast the differences between NFSv3 and NFSv4 name spaces, consider the mount of the root filesystem / in Figure 1. A mount of / over NFSv3 allows the client to list the post_contents of /vol/vol2 as the fsid for / and /vol/vol2 is the same. An NFSv4 mount of / over NFSv4 generates a pseudo fsid. As /vol/vol2 has not been exported and the pseudo filesystem does not contain it, it will not be visible. An explicit mount of vol/vol2 will be required.

The flexibility of pseudo-filesystems permits easier migration from NFSv3 directory structures to NFSv4, without being overly concerned as to the server directory hierarchy and layout. However, if there are applications that traverse the filesystem structure or assume the entire filesystem is visible, caution should be exercised before moving to NFSv4 to understand the impact presenting a pseudo filesystem, especially when converting NFSv3 mounts of / to NFSv4.

To read more about SNIA’s view of NFSv4 please read this white paper