6.1.4 Basic Data Types (original) (raw)

Connected: An Internet Encyclopedia
6.1.4 Basic Data Types

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1813
Up: 6. Appendix II: Lock manager protocol
Up: 6.1 RPC Information

Prev: 6.1.3 Transport Address
Next: 6.2 NLM Procedures

6.1.4 Basic Data Types

uint64 typedef unsigned hyper uint64;

int64 typedef hyper int64;

uint32 typedef unsigned long uint32;

int32 typedef long int32;

These types are new for the NLM version 4 protocol. They are the same as in the NFS version 3 protocol.

nlm4_stats

  enum nlm4_stats {
     NLM4_GRANTED = 0,
     NLM4_DENIED = 1,
     NLM4_DENIED_NOLOCKS = 2,
     NLM4_BLOCKED = 3,
     NLM4_DENIED_GRACE_PERIOD = 4,
     NLM4_DEADLCK = 5,
     NLM4_ROFS = 6,
     NLM4_STALE_FH = 7,
     NLM4_FBIG = 8,
     NLM4_FAILED = 9
  };

Nlm4_stats indicates the success or failure of a call. This version contains several new error codes, so that clients can provide more precise failure information to applications.

NLM4_GRANTED

The call completed successfully.

NLM4_DENIED

The call failed. For attempts to set a lock, this status implies that if the client retries the call later, it may succeed.

NLM4_DENIED_NOLOCKS

The call failed because the server could not allocate the necessary resources.

NLM4_BLOCKED

Indicates that a blocking request cannot be granted immediately. The server will issue an NLMPROC4_GRANTED callback to the client when the lock is granted.

NLM4_DENIED_GRACE_PERIOD

The call failed because the server is reestablishing old locks after a reboot and is not yet ready to resume normal service.

NLM4_DEADLCK

The request could not be granted and blocking would cause a deadlock.

NLM4_ROFS

The call failed because the remote file system is read-only. For example, some server implementations might not support exclusive locks on read-only file systems.

NLM4_STALE_FH

The call failed because it uses an invalid file handle. This can happen if the file has been removed or if access to the file has been revoked on the server.

NLM4_FBIG

The call failed because it specified a length or offset that exceeds the range supported by the server.

NLM4_FAILED

The call failed for some reason not already listed. The client should take this status as a strong hint not to retry the request.

nlm4_holder

  struct nlm4_holder {
       bool     exclusive;
       int32    svid;
       netobj   oh;
       uint64   l_offset;
       uint64   l_len;
  };

This structure indicates the holder of a lock. The exclusive field tells whether the holder has an exclusive lock or a shared lock. The svid field identifies the process that is holding the lock. The oh field is an opaque object that identifies the host or process that is holding the lock. The l_len and l_offset fields identify the region that is locked. The only difference between the NLM version 3 protocol and the NLM version 4 protocol is that in the NLM version 3 protocol, the l_len and l_offset fields are 32 bits wide, while they are 64 bits wide in the NLM version 4 protocol.

nlm4_lock

  struct nlm4_lock {
       string   caller_name<LM_MAXSTRLEN>;
       netobj   fh;
       netobj   oh;
       int32    svid;
       uint64   l_offset;
       uint64   l_len;
  };

This structure describes a lock request. The caller_name field identifies the host that is making the request. The fh field identifies the file to lock. The oh field is an opaque object that identifies the host or process that is making the request, and the svid field identifies the process that is making the request. The l_offset and l_len fields identify the region of the file that the lock controls. A l_len of 0 means "to end of file".

There are two differences between the NLM version 3 protocol and the NLM version 4 protocol versions of this structure. First, in the NLM version 3 protocol, the length and offset are 32 bits wide, while they are 64 bits wide in the NLM version 4 protocol. Second, in the NLM version 3 protocol, the file handle is a fixed-length NFS version 2 protocol file handle, which is encoded as a byte count followed by a byte array. In the NFS version 3 protocol, the file handle is already variable-length, so it is copied directly into the fh field. That is, the first four bytes of the fh field are the same as the byte count in an NFS version 3 protocol nfs_fh3. The rest of the fh field contains the byte array from the NFS version 3 protocol nfs_fh3.

nlm4_share

  struct nlm4_share {
       string      caller_name<LM_MAXSTRLEN>;
       netobj      fh;
       netobj      oh;
       fsh4_mode   mode;
       fsh4_access access;
  };

This structure is used to support DOS file sharing. The caller_name field identifies the host making the request. The fh field identifies the file to be operated on. The oh field is an opaque object that identifies the host or process that is making the request. The mode and access fields specify the file-sharing and access modes. The encoding of fh is a byte count, followed by the file handle byte array. See the description of nlm4_lock for more details.

Next: 6.2 NLM Procedures

Connected: An Internet Encyclopedia
6.1.4 Basic Data Types