After an object's file handle is available, the flow for a functional
request is as follows:
- The functional RPC is called with the object's file handle and
other parameters that are specific to this function.
- The VFS server uses the mount key from the file handle to find
the related mount RPC structure in which the VFS token from v_rpn() was
saved.
- v_get() is called with that VFS token and the
FID from the file handle. This returns the vnode token for the object
that is represented by the file handle.
- The appropriate VFS callable services API function is called to
perform the operation that is requested by the RPC. The parameters
of the call include the object's vnode token, from step 3, and the other parameters that are specific to this
function.
- v_rel() is called to release the object's vnode token.
- The data or results of the function are returned to the client.
So long as the client has cached a file handle, the pathname resolution
process does not have to be repeated, and files and directories can
be immediately accessed by their handle. In particular, this simpler
flow would be used for all reads and writes against an open file,
since the client can save the file handle with the open structures.
Note: - If the VFS server keeps enough state information, the v_get()-v_rel() pairs can be skipped by caching the vnode token that
is used on a sequence of inbound RPC requests. Because NFS clients
do not inform their servers when they are finished with a file handle,
a server that is caching vnode tokens must eventually clean them up
by calling v_rel(), after an inactivity timeout or with some
other reclamation algorithm.
- v_rpn() is the only VFS callable services API function
that takes a path name for the file it acts upon.