The existing filesystem interfaces may be characterized in several ways. Each system is centered around a few data structures or objects, along with a set of primitives for performing operations upon these objects. In the original UNIX filesystem [Ritchie74], the basic object used by the filesystem is the inode, or index node. The inode contains all of the information about a file except its name: its type, identification, ownership, permissions, timestamps and location. Inodes are identified by the filesystem device number and the index within the filesystem. The major entry points to the filesystem are namei, which translates a filesystem pathname into the underlying inode, and iget, which locates an inode by number and installs it in the in-core inode table. Namei performs name translation by iterative lookup of each component name in its directory to find its inumber, then using iget to return the actual inode. If the last component has been reached, this inode is returned; otherwise, the inode describes the next directory to be searched. The inode returned may be used in various ways by the caller; it may be examined, the file may be read or written, types and access may be checked, and fields may be modified. Modified inodes are automatically written back the filesystem on disk when the last reference is released with iput. Although the details are considerably different, the same general scheme is used in the faster filesystem in 4.2BSD UNIX [Mckusick85].
Both the AT&T interface and, to a lesser extent, the DEC interface attempt to preserve the inode-oriented interface. Each modify the inode to allow different varieties of the structure for different filesystem types by separating the filesystem-dependent parts of the inode into a separate structure or one arm of a union. Both interfaces allow operations equivalent to the namei and iget operations of the old filesystem to be performed in the filesystem-independent layer, with entry points to the individual filesystem implementations to support the type-specific parts of these operations. Implicit in this interface is that files may be conveniently be named by and located using a single index within a filesystem. The GFS provides specific entry points to the filesystems to change most file properties rather than allowing arbitrary changes to be made to the generic part of the inode.
In contrast, the Sun VFS interface replaces the inode as the primary object with the vnode. The vnode contains no filesystem-dependent fields except the pointer to the set of operations implemented by the filesystem. Properties of a vnode that might be transient, such as the ownership, permissions, size and timestamps, are maintained by the lower layer. These properties may be presented in a generic format upon request; callers are expected not to hold this information for any length of time, as they may not be up-to-date later on. The vnode operations do not include a corollary for iget; the only external interface for obtaining vnodes for specific files is the name lookup operation. (Separate procedures are provided outside of this interface that obtain a ``file handle'' for a vnode which may be given to a client by a server, such that the vnode may be retrieved upon later presentation of the file handle.)