There are several design goals which, in varying degrees, have driven the various designs. Each attempts to divide the filesystem into a filesystem-type-independent layer and individual filesystem implementations. The division between these layers occurs at somewhat different places in these systems, reflecting different views of the diversity and types of the filesystems that may be accommodated. Compatibility with existing local filesystems has varying importance; at the user-process level, each attempts to be completely transparent except for a few filesystem-related system management programs. The AT&T interface also makes a major effort to retain familiar internal system interfaces, and even to retain object-file-level binary compatibility with operating system modules such as device drivers. Both Sun and DEC were willing to change internal data structures and interfaces so that other operating system modules might require recompilation or source-code modification.
AT&T's interface both allows and requires filesystems to support the full and exact semantics of their previous filesystem, including interruptions of system calls on slow operations. System calls that deal with remote files are encapsulated with their environment and sent to a server where execution continues. The system call may be aborted by either client or server, returning control to the client. Most system calls that descend into the file-system dependent layer of a filesystem other than the standard local filesystem do not return to the higher-level kernel calling routines. Instead, the filesystem-dependent code completes the requested operation and then executes a non-local goto (longjmp) to exit the system call. These efforts to avoid modification of main-line kernel code indicate a far greater emphasis on internal compatibility than on modularity, clean design, or efficiency.
In contrast, the Sun VFS interface makes major modifications to the internal interfaces in the kernel, with a very clear separation of filesystem-independent and -dependent data structures and operations. The semantics of the filesystem are largely retained for local operations, although this is achieved at some expense where it does not fit the internal structuring well. The filesystem implementations are not required to support the same semantics as local UNIX filesystems. Several historical features of UNIX filesystem behavior are difficult to achieve using the VFS interface, including the atomicity of file and link creation and the use of open files whose names have been removed.
A major design objective of Sun's network filesystem, statelessness, permeates the VFS interface. No locking may be done in the filesystem-independent layer, and locking in the filesystem-dependent layer may occur only during a single call into that layer.
A final design goal of most implementors is performance. For remote filesystems, this goal tends to be in conflict with the goals of complete semantic consistency, compatibility and modularity. Sun has chosen performance over modularity in some areas, but has emphasized clean separation of the layers within the filesystem at the expense of performance. Although the performance of RFS is yet to be seen, AT&T seems to have considered compatibility far more important than modularity or performance.