Virtual File System

The Virtual File System (VFS), which is based on the Berkeley 4.3 Reno Virtual File System, provides a uniform interface abstracted from the file system layer which allows common access to files, regardless of the file system on which the files reside. contains information about each file in a mounted file system and is more or less a wrapper around file system-specific nodes. If, for example, a read or write is requested on a file, the vnode points the system call to the system call appropriate for that file system (a read request is pointed to a ufs_read if the request is made on a file in a UFS file system or to an nfs_read if the request is made on a file in an NFS-mounted file system). As a result, file access across different file systems is transparent to the user.

Digital's VFS implementation also supports Extended File Attributes (XFAs). Although originally intended to provide support for system security (Access Control Lists) and the Pathworks PC server (so that a Pathworks PC server could assign PC-specific attributes to a file, such as icon color, the startup size of the application, its backup date, and so forth), the XFA implementation was expanded to provide support for any application that wants to assign an XFA to a file. Currently, both UFS and AdvFS support XFAs, as well as the pax backup utility which has a tar and cpio front-end. XFAs are also supported for remote UFS file systems, to a server which supports a special protocol which currently only Digital supports. For more information on XFAs, see setproplist(2). For more information on pax, see pax(1).

Information for File System Developers

In Digital UNIX Version 4.0, the VOP_READDIR kernel vnode operation interface has been changed to accommodate a new structure, kdirent, in addition to the existing dirent structure.

The new kdirent structure was developed to make file systems other than UFS work properly over NFS.

Note, however, that if you implement a file system under Digital UNIX, you do not need to make any changes to your VOP_READDIR interface routine for Digital UNIX Version 4.0, and applications see the same interface as before the addition of the new kdirent structure.

Unlike the dirent structure, the kdirent structure has a kd_off field that subordinate file systems can set to point to the on-disk offset of the next directory entry. Arrays of struct kdirent must be padded to 8-byte boundaries, using the KDIRSIZE macro, so that the off_t is properly aligned; arrays of struct dirent are only padded to 4 bytes.

Each mounted file system has the option of setting the M_NEWRDDIR flag in the mount structure m_flag field. If the M_NEWRDDIR flag is set, then the routine calling VOP_READDER expects the readdir on that vnode to return an array of struct kdirent; if the M_NEWRDDIR flag is clear (the default), then the the readdir on that vnode returns an array of struct dirent.

In terms of NFS, if the M_NEWRDDIR flag is not set, then the NFS server uses the dirent structures and then calculates the necessary offset to pass back to the server. Thus, to ensure proper operation over NFS, any file system that does not have the M_NEWRDDIR flag set must be prepared to have VOP_READDIR called with offsets based on a packed array of struct dirent, which may be in conflict with the offsets on the on-disk directory structure. However, if the M_NEWRDDIR flag is set, then the NFS server uses the kd_off fields of the kdirent structures to generate the necessary offsets to pass back to the server.

A new vnode operation VOP_PATHCONF was added to the kernel in order to return filesystem-specific information for the fpathconf() and pathconf() system calls. This vnode operation takes as arguments the pointer to struct vnode, the pathconf name int, return value pointer to long and error int. It also sets the return value and ERRNO. Note that each filesystem must implement the vnode operation by providing a function in the vnodeops structure after the vn_delproplist component (at the end of the structure). This function takes as arguments the pointer to vnode, the pathconf name, and the return value pointer to long. The function sets the return value and returns zero for succes or an error number.