Creating, referring to, and inactivating file vnodes

The PFS creates vnodes by calling osi_getvnode, which is one of the OSI services in the OSIT vector table that is passed to the PFS during its initialization. The output of osi_getvnode is actually an 8-byte vnode token, but for the purposes of this discussion the vnode and the vnode token are the same, and the term vnode is used for both.

The first vnode for a mounted file system is created during vfs_mount processing. At this time, the PFS must create a vnode-inode pair to represent the root of the mounted file system and return the vnode token of the root. The LFS never inactivates this first vnode; it is cleaned up as part of vfs_umount processing.

Subsequent vnodes within a mounted file system are created by calls to vn_lookup, vn_create, vn_mkdir, or vfs_vget. The first three of these routines are passed a previously obtained directory vnode, represented by a token structure, and the name of a file within that directory to find or create.

The vfs_vget operation also generates vnodes directly from the file identifier (FID) of a file within a given file system. See Exporting files to a VFS server.

During vn_lookup the PFS must:

Look up the filename in the directory. If the name is not found, vn_lookup fails.
Find or create an inode that represents the named file. This may involve reading the file's control information from a disk when the file has not been referred to for a while.
For a new inode or one without a vnode (depending on PFS design), call osi_getvnode to create a vnode. The PFS's file token is passed to osi_getvnode to be saved in the vnode, and the returned vnode token is saved by the PFS in the inode.
Return the vnode token from the inode that represents the named file in the specified directory. The file may itself be another directory.

The creation operations of vn_create and vn_mkdir follow a similar flow. See Creating files for more information. They are also invoked with a directory vnode and a name, but in these cases the file itself is created if it does not exist. vn_lookup may create an inode, but it does not create the file.

The vnode is generally used in subsequent operations, such as vn_rdwr for a file or vn_lookup and vn_create for a directory. A directory vnode may become a mount point, the current root, or the working directory of POSIX processes. None of these references to the vnode involve any processing by the PFS.

Eventually the vnode falls out of use. After all opens have been closed and all other references to the vnode have been released, the LFS marks the vnode for inactivation. If the vnode is not referred to again for some time after it is marked for inactivation, the LFS invokes vn_inactive, or vfs_inactive if the PFS supports batch inactive and actually frees the vnode. The same functions are performed by vfs_inactive and vn_inactive; vfs _inactive requires only one call to the PFS to performs these functions for multiple vnodes.

During vn_inactive the PFS must:

Disassociate the inode from the vnode.
Perform any inode cleanup desired.
If the inode's link count is zero, it must be deleted; otherwise it is just deactivated and can be reactivated with vn_lookup.

After the call to vn_inactive, or vfs_inactive for multiple vnodes, LFS frees the vnode, unless the PFS reports a problem via a bad return code from the operation.

Porting note: The PFS does not free the vnode. This is a change from some implementations.

In cases in which a file is repeatedly opened and closed by a single process, the deactivation delay helps to avoid the cost of reconstructing the vnode-inode relationship, and whatever other overhead is incurred by a PFS in reactivating a file. In these cases, file caching is done by the LFS and need not be done by the PFS.

Serialization: The vn_lookup service is called with a shared latch held on the directory being searched. The vn_inactive service is called with an exclusive latch on the whole file system that the object belongs to.

The serialization of vn_inactive ensures that no operations are running that could possibly find, or attempt to create, the inode that is being processed by vn_inactive. This is because an exclusive latch is held on the inode's file system during vn_inactive and the LFS does not allow links across file systems, therefore no parent directory of the object that is being inactivated can be referred to while the PFS is trying to inactivate the object.

The PFS must serialize the creation of its own inodes, to ensure that a single file does not have two or more inodes. This is because the same file object may be looked up or created by more than one process concurrently. The PFS must atomically create the vnode-inode pair and associate the inode with the file object, either through a global latch or with a Compare and Swap algorithm.

To help with a Compare and Swap algorithm, a Return an Unused Vnode option is provided on osi_getvnode so that the Compare and Swap loser can free the vnode it had acquired. The vnode obtained from osi_getvnode does not represent anything until the PFS returns it to the LFS from this or another concurrent operation. The instant that the PFS associates a vnode-inode pair with an object, any vn_lookup for the same object that is running on another process must find this same vnode-inode pair.