Open Systems Transmission Analysis

Introduction

When an XSI System Interface function is applied to an XNFS file system object, the XNFS client implementation executes a sequence of NFS RPCs to the XNFS server in order to perform the requested operation. This appendix, describing transmission analysis, provides a general indication of the sequence of RPCs which is performed for each XSI System Interface function.

In a rudimentary implementation, it might be possible to define the precise sequence of RPCs that would be performed for each XSI function. However, this is unlikely to be feasible for any commercially available implementation of NFS within an X/Open-compliant system. Practical NFS implementations include various cache mechanisms, the purpose of which is to increase performance by not performing possibly redundant remote procedure calls. However the use of local caches can introduce "windows" in which the client's view of the state of the file system object is incorrect for a short period of time. For this reason, implementations will usually include mechanisms whereby the administrator of the XNFS client can disable some or all of the cache schemes, usually on a per-file system basis. The attributes of the MountedFileSystem which control this are described in XNFS Service Model .

This chapter describes the sequence of NFS RPCs corresponding to each of the most basic XSI System Interface functions. For example, read() is described, but fread() is not. This corresponds to the distinction between "system calls" and "library routines" which is made in some X/Open-compliant systems. For each function, the sequence of RPCs which would occur if all attribute and directory caching were disabled is described. This is followed by comments on the way in which the operation of the attribute or directory caches may alter the sequence.

The following general points should be noted:

• Attribute cache consistency.

  If attribute caching is enabled, an NFSPROC_GETATTR may be performed at any time in order to ensure cache consistency.

• Buffer cache operation.

  Data to be read will usually be buffered. This may mean that extra NFSPROC_READ requests may be issued at any time to load the buffers, and that read() requests may be satisfied from the buffered data, so that there is no obvious correlation between read() requests and NFSPROC_READ RPCs. Similarly, data which is written by write() and similar functions may be buffered, with the NFSPROC_WRITE being deferred. This specification does not define any mechanism whereby this data buffering may be disabled, but it is expected that an implementation will disable data buffering on a file for which record locking is in use.
  

• Looking up a path.

  Many of the XSI functions are invoked with a path which is to be interpreted as identifying a particular file system object. The process of interpreting a path is handled in a broadly similar manner for all functions, and is denoted by LOOKUP_SEQUENCE in the following descriptions:

  • If the path is relative to the current directory, issue an NFSPROC_GETATTR to verify that the directory is still valid.

  • For each component in the path, issue an NFSPROC_LOOKUP to retrieve the file handle and attributes for the corresponding file system object.

  If attribute caching is enabled, the initial NFSPROC_GETATTR call may not be needed. If directory caching is enabled, it may not be necessary to perform the NFSPROC_LOOKUP for some components; on the other hand it may be necessary to issue additional NFSPROC_GETATTR calls to verify that the cached state is up-to-date.

• Relationship to Service Model.

  Before an application can invoke XSI functions which refer to an NFS mounted file system, the file system must be mounted as described in XNFS Service Model . This creates a MountedFileSystem object which includes the file handle for the remote file system; this is then used during any LOOKUP_SEQUENCE which traverses the corresponding mount point.

• Version 2 versus Version 3.

  This appendix is derived from Version 2 of the NFS protocol. The sequence of RPCs using Version 3 of the protocol bears some resemblance to the sequence using Version 2, but it is complicated by features that exist only in Version 3, such as

  • New RPC procedures (for example, ACCESS and READDIRPLUS)

  • Pre- and post-operation attributes

  • Asynchronous WRITE calls

  These protocol features are discussed in more detail in XNFS: Protocol Specification, Version 3 .

RPC Calls Generated by Basic XSI Functions

ACCESS

The ACCESS() XSI System Interface function is implemented as follows:

• A LOOKUP sequence is performed to interpret the path.

• An NFSPROC_GETATTR is performed to retrieve the attributes of the object.

If attribute caching is enabled, the NFSPROC_GETATTR may not be performed.

CHDIR

The CHDIR() XSI System Interface function is implemented as follows:

• A LOOKUP sequence is performed to interpret the path.

• An NFSPROC_GETATTR is performed to retrieve the attributes of the object to verify that it is a directory.

If attribute caching is enabled, the NFSPROC_GETATTR may not be performed.

CHMOD

The CHMOD() XSI System Interface function is implemented as follows:

• A LOOKUP sequence is performed to interpret the path.

• An NFSPROC_GETATTR is performed to retrieve the attributes of the object.

• An NFSPROC_SETATTR is performed to update the attributes.

If attribute caching is enabled, the NFSPROC_GETATTR may not be performed.

CHOWN

The CHOWN() XSI System Interface function is implemented as follows:

• A LOOKUP sequence is performed to interpret the path.

• An NFSPROC_GETATTR is performed to retrieve the attributes of the object.

• An NFSPROC_SETATTR is performed to update the attributes.

If attribute caching is enabled, the NFSPROC_GETATTR may not be performed.

CHROOT

The CHROOT() XSI System Interface function is implemented as follows:

• A LOOKUP sequence is performed to interpret the path.

• An NFSPROC_GETATTR is performed to retrieve the attributes of the object and verify that it is a directory.

If attribute caching is enabled, the NFSPROC_GETATTR may not be performed.

CLOSE

The CLOSE() XSI System Interface function is implemented as follows:

• Any unwritten data is written to the file using NFSPROC_WRITE.

• If the file was unlinked while open, and this is the last reference to the file, it is finally unlinked using NFSPROC_REMOVE.

If the XNFS implementation supports the NoCto attribute for MountedFileSystems, and NoCto for the file system in question is "true", step (i) may be deferred.

CREAT

The CREAT() XSI System Interface function is implemented as follows:

• A LOOKUP sequence is performed to interpret the path.

• If "exclusive" mode is specified, an NFSPROC_LOOKUP will be performed to verify that the file does not already exist.

• An NFSPROC_CREATE is performed to create the file.

FCNTL

Certain subfunctions of the FCNTL() XSI System Interface function will lead to client-server interactions. The subfunctions are those concerned with advisory file locking, F_GETLK, F_SETLK and F_SETLKW. As noted in File Locking over XNFS , an implementation may elect to use synchronous or asynchronous requests for locking services. In addition, locking operations may cause the lock manager subsystems to initiate or terminate status monitoring. Here we consider only the case of synchronous lock manager interactions.

• For an F_GETLK request, the local NLM performs a synchronous NLM_TEST RPC to the remote NLM. If there are any conflicting locks on the file, the first of these is returned in the RPC reply.

• For an F_SETLK request to lock a file (with "l_type" set to F_RDLCK or F_WRLCK), the local NLM performs an NLM_LOCK RPC to the remote NLM. In addition, data and attribute caching are disabled for the file, in order that lock/update/unlock sequences can be performed synchronously.

• For an F_SETLK (or F_SETLKW) request to unlock a file (with "l_type" set to F_UNLCK), the local NLM performs an NLM_UNLOCK RPC to the remote NLM.

• For an F_SETLKW request to lock a file (with "l_type" set to F_RDLCK or F_WRLCK), the local NLM performs an NLM_LOCK RPC to the remote NLM with "block" set to true. If the request cannot be granted immediately, the server returns the code "LCK_BLOCKED". When the request can subsequently be honoured, the server NLM will perform an NLM_GRANTED RPC to the client NLM. If the client NLM does not wish to wait for the lock to be granted, it may perform an NLM_CANCEL RPC to the server NLM. As for F_SETLK, data and attribute caching are disabled for the file, in order that lock/update/unlock sequences can be performed synchronously.

FSTAT

The FSTAT() XSI System Interface function is implemented as follows:

• An NFSPROC_GETATTR is performed to retrieve the attributes of the object.

If attribute caching is enabled, the NFSPROC_GETATTR may not be performed.

FSYNC

The FSYNC() XSI System Interface function is implemented as follows:

• Any unwritten data is written to the file using NFSPROC_WRITE.

LINK

The LINK() XSI System Interface function is implemented as follows:

• A LOOKUP sequence is performed to interpret the path.

• An NFSPROC_GETATTR is performed to retrieve the attributes of the object.

• An NFSPROC_LINK is performed to create the link.

If attribute caching is enabled, the NFSPROC_GETATTR may not be performed.

LSEEK

The LSEEK() XSI System Interface function is implemented as follows:

• An NFSPROC_GETATTR is performed to retrieve the attributes of the object.

If attribute caching is enabled, the NFSPROC_GETATTR may not be performed.

MKDIR

The MKDIR() XSI System Interface function is implemented as follows:

• A LOOKUP sequence is performed to interpret the path.

• An NFSPROC_MKDIR is performed to create the directory.

• An NFSPROC_SETATTR is performed to set the group ID for the newly-created directory. (This step is necessary to accommodate a problem with certain server implementations.)

MKFIFO

The MKFIFO() XSI System Interface function is implemented as follows:

• A LOOKUP sequence is performed to interpret the path.

• An NFSPROC_CREATE is performed to create the file system object.

OPEN

The OPEN() XSI System Interface function is implemented as follows:

• A LOOKUP sequence is performed to interpret the path.

• An NFSPROC_GETATTR is performed to retrieve the attributes of the object.

• If "truncate" mode is required, an NFSPROC_CREATE is performed to create a new file.

If attribute caching is enabled, the NFSPROC_GETATTR may not be performed.

OPENDIR

The OPENDIR() XSI System Interface function is implemented as follows:

• A LOOKUP sequence is performed to interpret the path.

• An NFSPROC_GETATTR is performed to retrieve the attributes of the object to verify that it is a directory.

If attribute caching is enabled, the NFSPROC_GETATTR may not be performed.

PATHCONF

The PATHCONF() XSI System Interface function is implemented as follows:

• A LOOKUP sequence is performed to interpret the path.

READ

The READ() XSI System Interface function is implemented as follows:

• An NFSPROC_READ is performed to retrieve the data.

If data caching is enabled, the READ() may be satisfied using cached data. Note that the use of advisory file locking will disable caching for a file; see FCNTL() for more details.

READDIR

The READDIR() XSI System Interface function is implemented as follows:

• An NFSPROC_READDIR is performed to retrieve the next directory entry.

If directory caching is enabled, the NFSPROC_READDIR may be satisfied from the cached results of a previous NFSPROC_READDIR, provided that the directory information has not timed out and is more recent than the last modification time on the directory, which in turn depends on the (possibly cached) directory attributes.

RENAME

The RENAME() XSI System Interface function is implemented as follows:

• A LOOKUP sequence is performed to interpret the path.

• An NFSPROC_GETATTR is performed to retrieve the attributes of the object.

• An NFSPROC_RENAME is performed to rename the file.

If attribute caching is enabled, the NFSPROC_GETATTR may not be performed.

RMDIR

The RMDIR() XSI System Interface function is implemented as follows:

• A LOOKUP sequence is performed to interpret the path.

• An NFSPROC_RMDIR is performed to remove the directory.

STAT

The STAT() XSI System Interface function is implemented as follows:

• A LOOKUP sequence is performed to interpret the path.

• An NFSPROC_GETATTR is performed to retrieve the attributes of the object.

If attribute caching is enabled, the NFSPROC_GETATTR may not be performed.

UNLINK

The UNLINK() XSI System Interface function is implemented as follows:

• A LOOKUP sequence is performed to interpret the path.

• If the file is not open on the client system, an NFSPROC_REMOVE is performed to remove the file.

• If the file is open on the client system, an NFSPROC_RENAME is performed to rename the file temporarily.

WRITE

The WRITE() XSI System Interface function is implemented as follows:

• An NFSPROC_WRITE is performed to write the data.

If data caching is enabled, the data may be buffered and not written out immediately. In this case, if attribute caching is enabled, the cached attributes may be updated locally to reflect the new file size. Note that the use of advisory file locking will disable caching for a file; see FCNTL() for more details.