VFS functions

The virtual file system layer provides a standard way to deal with file system types without having to know anything about them. There is a vfs structure to hold general information of interest, such as the vnode on which this file system is mounted. The blocksize, some flags (like "mounted read-only"), and a list of function pointers round it out. The function list holds pointers to code for each file system type. These correspond to standard operations that need to be done for all file systems:

• vfs_mount() ” Mount the file system and make it accessible.

• vfs_unmount() ” Unmount the file system.

• vfs_root() ” Get the root vnode (the top of the file system)

• vfs_statvfs() ” Get statistics and information about the file system structure. (This function is known as vfs_statfs() in SunOS 4.x.)

• vfs_sync() ” Do a sync operation: Update the file system.

• vfs_vget() ” Convert a file ID into a real vnode pointer.

• vfs_mountroot() ” Mount the root file system at boot time.

• vfs_swapvp() ” Return a swap vnode pointer.

The definitions of the various VFS structures can be found in the header file /usr/include/sys/vfs.h on both SunOS 4.x and Solaris 2 systems.

Any user system calls relating to a file system (such as mount or umount ) will go through the VFS structure. The remainder of the functions are primarily for internal kernel use to traverse the file system tree.

Vnodes

The organization and use of a vnode structure is similar to that of a vfs structure. Some general information about the file is not dependent on the type of the file system that holds it. This information includes a reference count, indicating how many structures are referencing the vnode ( essentially an " open " count); a file-type code; a pointer to the vfs structure for the file system in which this file appears; a pointer to a list of pages that currently contain data from this file. There is also a "vector" of vnode operations, composed of a list of functions to perform certain tasks . The actual routine names will be file-type specific, but they must all implement the same basic operations. This is a fairly long list (documented in the header file /usr/include/sys/vnode.h ), which includes operations such as:

• vop_open() ” Perform an open system call.

• vop_getattr() ” Obtain attributes from a file. These attributes include things like owner, size , update time, and permissions.

• vop_lookup() ” Perform directory search operations.

• vop_create() ” Create a new file.

• vop_remove() ” Delete a file.

• vop_rename() ” Rename a file or directory. This operation may actually change the location of the file in the directory hierarchy.

• vop_mkdir() ” Create a new directory.

• vop_fid() ” Build a "file identifier" structure, which uniquely identifies a file inside a particular file system.

• vop_getpage() ” Read in from the file all the pages that make up a given range of data (pass in an offset and a length).

• vop_map() ” Perform an mmap system call (calls as_map() to set up the new mapping).

These operations take care of all the system calls that need to access data specific to a file, and they perform various housekeeping functions, for example, I/O on the file or locating a file in the file system.

General VFS & vnode operations

Some general operations performed with vnodes or the VFS structure are not dependent on file system type, so there are functions to deal with these. Some of these just deal with filenames (paths), such as lookuppn() (look up path name ), which processes a user-supplied filename, traversing the directories to find the actual desired file. Others handle the dnlc , or directory name lookup cache. This cache keeps a list of frequently used pathnames and a pointer to the vnode resulting from this path, making common searches much faster. Rather than actually traversing the entire path and searching all the intermediate directories, the name can be found immediately in the cache. Some of these functions are dnlc_enter() and dnlc_lookup() .

Other generic functions handle common vnode operations that do not need specific information about the file to do their job. They also implement higher-level checking or validation on system calls that may eventually go through the vnode operations list to finish with type-specific functions. These generic functions include:

• vn_rele() ” Release a vnode by decrementing the reference count and actually removing it once the count drops to zero.

• vn_rdwr() ” Perform actual read/write operations.

• vn_create() ” Build a new vnode.

Many of these routines will eventually need to find out file-specific information or will need to have lower-level functions do some of the work to take care of details that are file system specific, like how the directories are organized and how a new file is actually created.

Let's examine a few of the functions that the UFS-specific code provides.