14.3. Solaris File System Framework The vnode/vfs interfacesthe "top end" of the file system moduleimplement vnode and vfs objects. The "bottom end" of the file system uses other kernel interfaces to access, store, and cache the data they represent. Disk-based file systems interface to device drivers to provide persistent storage of their data. Network file systems access remote storage by using the networking subsystem to transmit and receive data. Pseudo file systems typically access local kernel functions and structures to gather the information they represent. Loadable file system modules. A dynamically loadable module type is provided for Solaris file systems. File system modules are dynamically loaded at the time each file system type is first mounted (except for the root file system, which is mounted explicitly at boot). The vnode interface. As discussed, this is a unified file-system-independent interface between the operating system and a file system implementation. File system caching. File systems that implement caching interface with the virtual memory system to map, unmap, and manage the memory used for caching. File systems use physical memory pages and the virtual memory system to cache files. The kernel's seg_map driver maps file system cache into the kernel's address space when accessing the file system through the read() and write() system calls. (See Section 14.8.1.) Path-name management. Files are accessed by means of path names, which are assembled as a series of directory names and file names. The file system framework provides routines that resolve and manipulate path names by calling into the file system's lookup() function to convert paths into vnode pointers. Directory name caching. A central directory name lookup cache (DNLC) provides a mechanism to cache pathname-to-vnode mappings, so that the directory components need not be read from disk each time they are needed.
14.3.1. Evolution of the File System Framework Solaris 10 introduces a new file system interface that significantly improves the portability of file systems. In prior releases of Solaris OS, the vnode and vfs structures were entirely visible to their consumers. A file system client would reference, manipulate, or update raw vfs and vnode structure members directly, which meant that file systems had operating system revision-specific assumptions compiled into them. Whenever the vfs or vnode structures changed in the Solaris kernel, file systems would need to be recompiled to match the changes. The new interface allows the vnode structures to change in many ways without breaking file system compatibility. The new model replaces the old file system VOP macros with a new set of functions. The goals of the new interface are as follows: It separates the vnode from FS-dependent node so that changes in the vnode structure that affect its size do not affect the size of other data structures. It provides interfaces to access nonpublic vnode structure members. It delivers a flexible operation registration mechanism that provides appropriate defaults for unspecified operations and allows the developer to specify a corresponding default or error routine. It delivers a flexible mechanism to invoke vnode/vfs operations without requiring the client module to have knowledge of how the operations are stored. It provides a facility for creation, initialization, and destruction of vnodes. It provides accessor functions for file systems that require information on the following characteristics of a vnode: existence of locks, existence of cached data, read-only attribute.
The following major changes have been made to the file system interface as part of this project: The following related vnode fields are now private: v_filocks, v_shrlocks, v_nbllock, v_pages and v_cv. Support routines allow a vnode/vfs client to set a vnode's or vfs's operations, retrieve the operations, compare the operations vector to a given value, compare a specific operation in the operations vector to a given value. The related vnode field v_op and the related vfs field vfs_op should not be directly accessed by file systems. An accessor routine returns a pointer to the vfs, if any, which may be mounted on a given vnode. Another routine determines whether a given vnode is mounted on. The related vnode field v_vfsmountedhere is now private. An operation registration mechanism can fill in default operation values (if appropriate) for operations that are not explicitly specified by the file system. The operation registration mechanism enables developers to add new operations to a new (updated) version of Solaris OS without requiring existing file systems to support those new operations, provided that the new operations have system-defined defaults. The file system module loading mechanism is updated to enable these changes. Vnodes are no longer embedded in file system data structures (for example, inodes). The following functions have been added to support the separation of the vnode from the FS-dependent node: vn_alloc(), vn_free(), and vn_reinit(). Certain fields in the vnode have been made "private" to satisfy the requirements of other projects. Also, the fields in the vnode have been rearranged to put the "public" structure members at the top and the private members at the bottom. File systems now register their vnode and vfs operations by providing an operation definition table that specifies operations by using name/value pairs. The VOP and VFSOP macros no longer directly dereference the vnode and vfs structures and their operations tables. They each call corresponding functions that perform that task. File system module loading no longer takes a vfs switch entry. Instead, it takes a vfsdef structure that is similar. The difference is that the vfsdef structure includes a version number but does not include a vfsops table.
The following accessor functions have been added to provide information about the state and characteristics of a vnode. vn_is_readonly(). Returns non-zero if the vnode is on a read-only file system. vn_has_flocks(). Returns non-zero if the vnode has active file locks. vn_has_mandatory_locks(). Returns non-zero if the vnode has mandatory locks. vn_has_cached_data(). Returns non-zero if the vnode has pages in the page cache. vn_mountedvfs(). Returns the vfs mounted on this vnode, if any. vn_ismntpt(). Returns true (non-zero) if this vnode is mounted on, zero otherwise.
New interfaces have been developed to register vnode and vfs operations. vn_make_ops(). Creates and builds the private vnodeops table. vn_freevnodeops(). Frees a vnodeops structure created by vn_make_ops(). vfs_setfsops(). Builds a vfsops table and associates it with a vfs switch table entry. vfs_freevfsops_by_type(). Frees a vfsops structure created by vfs_makefsops(). vfs_makefsops(). Creates and builds (dummy) vfsops structures. vfs_freevfsops(). Frees a vfsops structure created by vfs_makefsops().
The following support routines have been developed to set and provide information about the vnode's operations vector. vn_setops(). Sets the operations vector for this vnode. vn_getops(). Retrieves the operations vector for this vnode. vn_matchops(). Determines if the supplied operations vector matches the vnode's operations vector. Note that this is a "shallow" match. The pointer to the operations vector is compared, not each individual operation. vn_matchopval(). Determines if the supplied function exists for a particular operation in the vnode's operations vector.
The following support routines have been developed to set and provide information about the vfs's operations vector. vfs_setops(). Sets the operations vector for this vfs. vfs_getops(). Retrieves the operations vector for this vfs. vfs_matchops(). Determines if the supplied operations vector matches the vfs's operations vector. Note that this is a "shallow" match. The pointer to the operations vector is compared, not each individual operation. vfs_can_sync(). Determines if a vfs has an FS-supplied (nondefault, non-error) sync routine.
14.3.2. The Solaris File System Interface The file system interface can be categorized into three major parts: A single systemwide, file system module-specific declaration A per-file system mount instance declaration A set of per-file operations with each file system mount instance
|
