Using NFSv4

Support for NFSv4

Data ONTAP supports all of the mandatory functionality in NFSv4, except the SPKM3 and LIPKEY security mechanisms, including the following:

COMPOUND--Allows a client to request multiple file operations in a single remote procedure call (RPC) request.
File read delegation--Allows the server to delegate file control to some client types for read-only access.
Pseudo-fs--Used by NFSv4 servers to determine mount points on the filer. There is no mount protocol in NFSv4.
Locking--Lease-based. There are no separate Network Lock Manager (NLM) or Network Status Monitor (NSM) protocols in NFSv4.
Named attributes--Similar to Windows NT streams.

Limitations for NFSv4

Be aware of the following limitations when using NFSv4 with Data ONTAP:

Delegation feature includes read-only file access, but not write access.
Delegation feature is not supported by every client type.
Named attributes can only be created if CIFS is running on the filer.
Names with non-ASCII characters on volumes other than UTF8 volumes are rejected by the filer.
All file handles are persistent. The server does not give volatile file handles.
Migration and replication are not supported.
NFSv4 access control lists (ACLs) are not supported. ACLs set by CIFS apply to NFSv4 access, as they do for other versions of NFS.
All recommended attributes are supported, except for the following:
- acl
- aclsupport
- archive
- hidden
- homogeneous
- mimetype
- quota_avail_hard
- quota_avail_soft
- quota_used
- system
- time_backup
NFSv4 does not use the User Datagram Protocol (UDP) transport protocol. If you enable NFSv4 and disable NFS over TCP by setting options nfs.tcp.enable to Off, then NFSv4 is effectively disabled.

How NFSv4 delegation features work on the filer

NFSv4 provides server-to-client delegation for file operations. The filer currently supports delegation of read operations only.

Delegation of file operations can reduce latency, particularly in environments that

Exhibit a high volume of file open and close requests
Place a heavy load on the server, with a large number of clients and concurrent read sharing operations
Already strain resources because of a high load or numerous clients
Already demonstrate file access latency problems
Have a large number of fast clients trying to access files

Client support for read delegation

Read delegations are only supported over NFSv4 (not over prior NFS versions). To verify that a specific client type supports read delegation, see the client operating system documentation or feature support documentation.

Prerequisites for filer delegation

Delegation of file operations requires the following configuration criteria to be met:

The requesting client must support delegation and be running NFSv4.
No other client has the file open for writing or "deny read."
There is a recall path present, so the filer can revoke the delegation.

Delegation works on files within any style of qtree, whether or not oplocks have been enabled.

Revocation of read delegation

Delegation of file operations to a client can be revoked when the lease expires, or when the filer receives the following requests from another client:

Write to file, open file for writing, or open file for "deny read"
Change file attributes
Rename file
Delete file

Delegation state recovery

When the server reboots, the delegation state is lost. However, information about delegated files is preserved. Clients may reclaim the delegation state upon reconnection, instead of going through the entire delegation request process again. When a client holding a read delegation reboots, all delegation state information will be flushed from the filer cache upon reconnect. The client must issue a delegation request to establish a new delegation.

Enabling and disabling read delegation

By default, read delegation is enabled. To modify the read delegation setting, complete the following step.

Step	Action
1	Enter the following command: options nfs.v4.read_delegation on\|off [on]

Note
The read delegation option takes effect as soon as it is changed. There is no need to reboot the filer following this command.

Retrieving delegation statistics

Use the nfsstat command to retrieve information about read delegation requests, as described in the following sections. Results returned by the nfsstat command include delegation requests that have been granted as well as requests that have been denied due to an error. For information about delegation requests your filer has denied, view the system log file.

You can view delegation information:

Per client
Per vFiler
Per filer

Use the procedures described in the following sections to retrieve delegation information.

Viewing delegation statistics for all clients

To view delegation information for all clients, complete the following step.

Step	Action
1	Enter the following command: nfsstat -h

The filer will return individual delegation statistics for each client.

Viewing delegation statistics for a specific client

To view delegation information for a specific client, complete the following step.

Step

Action

1
Enter the following command:

nfsstat -h <hostname or ip_address>

Step	Action
1	Enter the following command: *nfsstat -h <hostname* or ip_address>**

The filer will return individual delegation statistics for the specified client.

Viewing delegation statistics for a vFiler

To view delegation information specific to a vFiler, complete the following step.

Step	Action
1	Enter the following command: *vfiler run <filername> nfsstat -d*

Viewing delegation statistics for a filer

To view delegation information specific to a filer, complete the following step.

Step	Action
1	Enter the following command: nfsstat -d

How the pseudo-fs in NFSv4 affects mount points

NFSv4 uses a pseudo-fs (file system) a as an entry point into the filer for determining mount points. A pseudo-fs allows you to use one port for security, rather than several. All NFSv4 servers support the use of a pseudo-fs.

You may experience inconsistencies with mount points between NFSv3 and NFSv4, because of the pseudo-fs used in NFSv4.

In the examples that follow, you have these volumes:

/vol/vol0 (root)
/vol/vol1
/vol/home

Example 1

In NFSv3 if you do not use the complete path from /vol/vol0, and you mount filer:/, the mount point is filer:/vol/vol0. That is, if the path does not begin with /vol in NFSv3, then Data ONTAP adds /vol/vol0 to the beginning of the path.

In NFSv4, if you do not use the complete path from /vol/vol0 and you mount filer:/, you mount the root of the pseudo-fs and not /vol/vol0. Data ONTAP does not add /vol/vol0 to the beginning of the path.

Therefore, if you mount filer:/ /n/filer using NFSv3 and try the same mount using NFSv4, you would mount a different file system.

Example 2

In Data ONTAP's implementation of the NFSv4 pseudo-fs, the nodes "/" and "/vol" are always present and form the common prefix of any reference into the pseudo-fs. Any reference that does not begin with "/vol" is invalid.

In this example, there is a /vol/vol0/home directory. In NFSv3, if you mount filer:/home/users, /home is considered as the directory /vol/vol0/home. In NFSv4, if you mount filer:/home/users, /home is not interpreted as the volume /vol/home; it is considered an invalid path in the pseudo-fs tree.

Specifying the user ID domain for NFSv4

The domain that Data ONTAP uses for NFSv4 user ID mapping by default is the NIS domain, if one is set. If an NIS domain is not set, the DNS domain is used. You might need to set the user ID domain if, for example, you have multiple user ID domains.

To specify the user ID domain to be used for NFSv4 user ID mapping, complete the following step.

Step	Action
1	Enter the following command: options nfs.v4.id_domain domain